A simple, implementation-oriented payments page: what to compare across banks for payment initiation, approvals, status reporting, real-time rails, controls, and reconciliation readiness.
Most client problems show up in status, exceptions, and reconciliation, not payment initiation.
API, host-to-host/file, portal, SWIFT. Many clients use two or more.
Dual approvals, role models, audit trails, limits, and segregation of duties. Connectivity must map to controls.
Acceptance/rejection, processing states, returns, and investigation workflows. This drives reconciliation success.
Instant payment infrastructure changes expectations for confirmation and operating hours. Market-specific.
Structured data improves automation if mapping is done correctly. It can also create new exception types.
Compare what banks document publicly (onboarding steps, sandbox visibility, status/event docs) and what is not visible.
Use this to align scope across treasury, IT, and the bank.
| Step | What happens | Key design question |
|---|---|---|
| 1. Create | ERP/TMS creates a payment instruction. | Which fields are mandatory (including ISO fields)? |
| 2. Approve | Approvals happen in ERP/TMS, bank portal, or a workflow tool. | Where is the control plane and audit trail? |
| 3. Send | Payment is transmitted via API or file/H2H/SWIFT. | How do retries and duplicates get handled? |
| 4. Acknowledge | Bank returns acceptance/rejection acknowledgement. | How fast do you need it and in what format? |
| 5. Track | Status updates flow back (polling, callbacks, statements). | Do you have a single payment ID across systems? |
| 6. Reconcile | Statements and events match to ERP/TMS records. | Who owns mapping and exception repair? |