Skip to content

Bank Transfers

Jump to bottom
Antonio Membrides Espinosa edited this page Jul 11, 2026 · 2 revisions

Bank Transfers (ACH / SEPA / SWIFT): end-user guide

The PSP can send money to bank accounts over three rails. This guide shows how to run each one, what the system validates, and how approvals, blocks and errors surface. For ready-to-use test data see the Test Dataset.

Where

/system/transfer/bank (customer login). Two tabs:

  • Registered account: send to a saved contact (beneficiary). No bank details needed. (Own-account to own-account transfers are not available yet.)
  • New bank account: send to an account not saved in your profile. Enter the details on the form.

How the rail is chosen

The system auto-detects the rail from the destination and shows it as a badge. You can override it.

You provide Detected rail
EUR + IBAN in an EEA country SEPA
USD + US routing number + account number ACH
A BIC for a cross-border account SWIFT

Validation runs live before you can send: IBAN (ISO 13616), BIC (ISO 9362), ACH routing (NACHA checksum). The fee for the detected rail is shown (SEPA free, ACH low, SWIFT higher, plus a correspondent surcharge).

Sending a one-off transfer (new account)

  1. Open the "New bank account" tab.
  2. Enter destination country and the account coordinates (IBAN, or routing + account number, plus BIC for SWIFT).
  3. Check the detected rail badge and the quoted fee.
  4. Enter the amount and an optional payment reference.
  5. Click Send wire. The transfer is submitted and the status updates live: pending settlement -> settled (or failed).

Re-submitting the same transfer with the same idempotency key will not send it twice.

Setting up a recurring payment (Direct Debit)

  1. Fill in the destination and amount as above (SEPA or ACH only).
  2. Tick Set up as a recurring payment (Direct Debit) and choose a frequency (weekly / monthly / quarterly / yearly).
  3. Click Create mandate. A SEPA SDD or ACH Direct Debit mandate is created; the system runs each collection automatically on schedule.

Approvals, blocks and errors

Before any funds move, every transfer is screened by fraud (FDS), sanctions (HRP) and AML monitoring:

  • A sanctions match, a fraud block, or a high/critical AML alert blocks the transfer and opens a fraud investigation case for an L1 analyst to review. The transfer shows an exception status.
  • Invalid coordinates (bad IBAN/BIC/routing) are rejected at validation with a clear message.
  • An unsupported country/currency/details combination results in an exception (no supported rail).
  • Rail-level problems surface with standard codes: ACH returns (e.g. R01 insufficient funds, R02 account closed), SEPA rejects (e.g. AC01 incorrect account), SWIFT cross-border errors.

Notes

  • Unregistered destinations are transaction-scoped (bound to this single transfer). To reuse a destination, add it as a contact under Beneficiaries first, then send from the "Registered account" tab. (A "Save this account" checkbox may appear on the form, but persisting a new destination from here is not wired up yet; use Beneficiaries to save one.)
  • Re-submitting with the same idempotency key does not send twice on the customer-login channel.
  • In the demo, transfers are simulated end to end (sandbox); settlement arrives after a short delay.

Clone this wiki locally