Workflow Engine
The PayPlus Workflow Engine controls how payment instructions move through validation, approval, compliance screening, and submission to the payment network. Administrators configure the workflow to match the institution's operational controls, segregation of duty requirements, and risk appetite.
Payment Lifecycle States
Every payment in PayPlus moves through a defined set of states. The transition between states is governed by the workflow configuration and the actions taken by operations staff.
Review
| State | Description | Who Can Act |
|---|---|---|
| Draft | Payment instruction entered but not yet submitted for processing. The initiator can edit or delete the payment. | Payments Processor (owner only) |
| Validated | Payment has passed format validation (mandatory fields, ISO 20022 schema compliance, NACHA field rules). Not yet approved or screened. | System (automatic transition) |
| Compliance Hold | Payment has matched an OFAC screening rule or hit a compliance threshold. Held for Compliance Officer review before further processing. | Compliance Officer (release or reject) |
| Pending Approval | Payment is awaiting approval from a Payments Manager. Triggered when dual-control workflow is configured and the payment meets the approval threshold. | Payments Manager (approve or reject) |
| Approved | Payment has passed all approval and compliance steps. Queued for submission to the rail connector at the next applicable processing window. | System (queued for submission) |
| Submitted | Payment has been transmitted to the payment network. Awaiting settlement confirmation (for batch rails) or real-time acceptance (for instant rails). | System |
| Settled | Payment has been confirmed as settled by the payment network. For ACH, settlement confirmation is received from FedACH. For Fedwire/RTP/FedNow, settlement is immediate upon acceptance. | System (terminal state) |
| Rejected | Payment was rejected at validation, compliance review, approval, or by the payment network. Rejection reason is captured in the payment record. | System / Compliance Officer / Payments Manager (terminal state) |
| Returned | Payment was accepted by the network but subsequently returned (ACH R-code returns, RTP return for invalid account). Returned payments require operations action. | Payments Manager (action required) |
Approval Workflow Configuration
PayPlus supports three approval workflow models. Configure the model at Administration > Workflow > Approval Settings, independently for each payment rail.
| Workflow Model | Description | Applicable Scenarios |
|---|---|---|
| STP — No Approval Required | Payments pass directly from Validated to Approved state without a manual approval step. Compliance screening still occurs. | Low-value payments below defined threshold; automated batch ACH from host systems via API; receive-only FedNow processing |
| Single Approval | Payment requires approval by one Payments Manager before submission. The initiating Payments Processor cannot approve their own payment. | Mid-value payments; institutions with lighter approval requirements |
| Dual Control | Payment requires approval from two separate Payments Managers. The initiating processor and the first approver cannot also be the second approver. Required for high-value wire transfers at most institutions. | High-value Fedwire and SWIFT transactions; all transactions above a defined limit regardless of rail |
Configuring Amount Thresholds
Configure approval thresholds at Administration > Workflow > Amount Thresholds. Thresholds are configured per rail and per user role. Payments below the STP threshold pass without approval; payments above the dual-control threshold require dual approval.
| Threshold | Behavior | Configuration Path |
|---|---|---|
| STP Limit | Payments at or below this amount are automatically approved (no manual approval required) | Workflow > Thresholds > STP Limit (per rail) |
| Single Approval Limit | Payments above STP Limit and at or below this amount require single-manager approval | Workflow > Thresholds > Single Approval Limit |
| Dual Control Threshold | Payments above this amount require dual-control approval from two separate managers | Workflow > Thresholds > Dual Control Threshold |
Rules Engine
The PayPlus Rules Engine evaluates each payment against a configurable set of business rules before processing. Rules can route payments to specific approval queues, flag payments for additional review, block payment submission, or modify processing parameters.
Rule Types
| Rule Type | Description | Example |
|---|---|---|
| Routing Rule | Determines which payment rail to use for a given payment instruction, based on beneficiary bank participation, amount, and customer preferences. | If Receiving Bank participates in FedNow AND amount ≤ $500,000 → route to FedNow; else if participates in RTP → route to RTP; else route to Fedwire |
| Approval Routing Rule | Directs a payment to a specific approval queue or approver group, overriding the default approval workflow. | If payment type = international SWIFT AND amount > $1,000,000 → route to Treasury Manager approval queue |
| Block Rule | Prevents payment submission based on defined criteria. Blocked payments are rejected with the configured rejection reason. | If beneficiary country = sanctioned country → block; If transaction type = RTP AND beneficiary is first-time payee AND amount > $10,000 → block (pending verification) |
| Enrichment Rule | Automatically adds or modifies payment fields based on rule conditions. Used to populate mandatory ISO 20022 fields or apply institution-specific codes. | If payment purpose code is blank AND payment type = payroll → set purpose code to SALA |
| Velocity Control Rule | Limits the number or value of payments from a specific originator or to a specific beneficiary within a defined time window. | Maximum 5 RTP payments per customer per hour; Maximum $50,000 cumulative FedNow per customer per day |
Creating a Rule
Navigate to Administration > Workflow > Rules Engine > Add Rule.
- Enter a Rule Name and optional description. Names must be unique across all rule types.
- Select the Rule Type (Routing, Approval Routing, Block, Enrichment, or Velocity Control).
- Define the Conditions using the rule builder. Multiple conditions can be combined with AND / OR logic. Available condition fields include: payment amount, payment rail, originator ID, beneficiary bank routing number, beneficiary country, payment purpose code, time of day, day of week.
- Define the Action that the rule applies when all conditions are met.
- Set the Rule Priority (1 = highest priority). When multiple rules apply to the same payment, the highest-priority rule takes effect.
- Select the Effective Date (future dating allows rules to be pre-configured before activation).
- Click Save and Test to validate the rule against a sample payment before activating it in production.
Straight-Through Processing (STP) Configuration
STP allows eligible payments to be automatically processed without manual intervention — from initiation through compliance screening to network submission. STP is appropriate for standardized, low-risk, high-volume payment types (e.g., payroll ACH batches originating from the core banking system via API).
| STP Eligibility Criterion | Configuration |
|---|---|
| Payment amount at or below STP Limit | Configured in Workflow > Thresholds (per rail) |
| Payment originates from trusted API source | Configure trusted API Integration User in Administration > Users; payments from this user bypass manual initiation approval |
| Beneficiary on pre-approved list | Workflow > STP Beneficiary Whitelist — payments to whitelisted beneficiary accounts skip approval step |
| No OFAC match | Automatic — payments with OFAC screening result of CLEAR proceed; MATCH or POSSIBLE MATCH always enter compliance hold regardless of STP configuration |
| Payment type is NACHA Standard (non-SDA) | Standard ACH processing qualifies for STP; Same-Day ACH payments above $5,000 require approval regardless of STP threshold |
Payment Templates
Payment templates store pre-configured payment instructions for recurring or standardized payments — reducing data entry errors and processing time for high-frequency transactions.
Navigate to Administration > Workflow > Payment Templates to create templates. Templates can be restricted to specific roles (e.g., only Payments Manager can create templates; Payments Processor can use but not create templates).
| Template Field | Template Behavior |
|---|---|
| Beneficiary name and account | Fixed — cannot be modified when using the template |
| Payment rail | Fixed — template is rail-specific |
| Payment amount | Optional — can be fixed (recurring fixed payment) or left open for operator entry at initiation |
| Payment purpose / remittance | Pre-populated but editable at initiation |
| Approval workflow | Inherits the standard workflow; templates do not override approval thresholds |
Bulk Payment Processing
PayPlus supports bulk ACH batch processing for high-volume origination scenarios — payroll, vendor disbursements, benefits payments. Bulk files can be uploaded via the Web Console or submitted via the API.
- Prepare the batch file. Format the batch as a NACHA-compliant file, or as a PayPlus-format CSV/XML (PayPlus will generate the NACHA file automatically). Make sure all required fields — ABA, account number, amount, SEC code, addenda — are populated.
- Upload the batch file via Payments > Bulk Upload or submit via the REST API endpoint
POST /api/v2/payments/ach/batch. - Validation pass: PayPlus validates all records in the batch. Invalid records are flagged individually. The batch can be submitted with valid records only, or returned to the originator for correction.
- Compliance screening: Each transaction in the batch is screened individually against OFAC. Matches are held; clean transactions continue to approval.
- Batch approval: If batch approval is required (configured in Workflow > Bulk Processing Settings), a Payments Manager approves the batch as a whole — individual items don't need separate approval.
- NACHA file submission: PayPlus generates the NACHA file, calculates hash totals, and submits to FedACH or EPN at the next processing window.