Interactive Payment Trace
One payment, USD 25,000 from London to Singapore. Select a stage and watch it travel. At every stage, see the incoming data, the processing logic, the outgoing message, the system response, and what can fail.
Stage 1 of 20
Stage 1: Customer Channel
Incoming data. A London corporate treasurer logs into Meridian Bank online banking and enters a supplier payment of USD 25,000 to Harbour Bank Singapore, with the beneficiary name, account number, invoice reference INV-8841 and value date 5 November 2026.
Processing logic. The channel checks the form is complete, confirms the beneficiary details are present, shows the customer the amount, charges and value date, and holds the instruction in a draft state awaiting approval. No ledger entry is made yet and the payment state is entered.
Outgoing message. The draft instruction is passed to the authentication service with the debtor account, beneficiary details, amount, currency, value date and reference PAY-2026-1105-25000 attached, ready for the customer to approve it securely.
System response. The authentication service confirms it has received the instruction and returns a challenge request, so the channel prompts the treasurer to approve the payment with a one time code or a hardware token.
What can fail.
- Customer session times out before approval, so the instruction is never sent.
- Beneficiary account number fails the format check and the channel rejects the entry.
- Customer enters the wrong one time code three times and the session is locked.
Stage 2: Authentication Service
Incoming data. The authentication service receives the draft instruction for USD 25,000 with reference PAY-2026-1105-25000, the debtor account, the beneficiary details and the device and session data of the treasurer who entered it.
Processing logic. The service checks the treasurer credentials, verifies the device, and issues a strong customer authentication challenge under SCA rules, matching the approval to the exact amount and beneficiary before it can proceed. The payment state moves to awaiting authentication.
Outgoing message. The approved instruction, signed with the authentication result and the challenge reference, is sent to the payment hub intake for processing, with the treasurer identity, approval time and authentication method attached to the record.
System response. The payment hub confirms receipt of the authenticated instruction, assigns the payment reference PAY-2026-1105-25000, and returns an acceptance so the channel can show the customer the payment is now in progress.
What can fail.
- The treasurer fails the authentication challenge, so the instruction is rejected and no payment is created.
- The device is not recognised, so the service asks for extra verification and the payment waits.
- The authentication service is unavailable, so the approval cannot complete and the draft is saved.
Stage 3: Payment Hub
Incoming data. The payment hub receives the authenticated instruction from the channel, with the debtor GBP account, the USD 25,000 amount, the Harbour Bank Singapore beneficiary details, the value date and reference PAY-2026-1105-25000.
Processing logic. The hub assigns an internal payment identification, stamps the receipt time, stores the instruction in the payment database, and sets the state to received. No funds move yet, so the ledger is untouched and the customer account balance is unchanged.
Outgoing message. The stored instruction is passed to the validation engine with the full debtor and creditor data, the amount, currency, value date and reference attached, ready for format and business rule checks to begin.
System response. The validation engine confirms it has queued the instruction, and the hub updates the customer tracking view to show the payment as received, with the reference and the expected value date visible to the treasurer.
What can fail.
- The hub cannot store the instruction because the database is unavailable, so the payment is not accepted.
- The instruction arrives without an authentication result, so the hub rejects it as unauthorised.
- A system restart loses the queued instruction, so the channel must resend it with the same reference.
Stage 4: Payment Hub Validation
Incoming data. The validation engine receives the stored instruction for USD 25,000 to Harbour Bank Singapore, with the debtor and creditor names, account numbers, BIC, value date, remittance reference INV-8841 and charge bearer SHA.
Processing logic. The engine checks the message format, the BIC and account structure, the currency and amount limits, the value date against business calendars, and the mandatory fields for the SWIFT route. The payment state stays received and no ledger entry is made while checks run.
Outgoing message. The instruction passes all checks and is sent to the duplicate detection service with the validated debtor, creditor, amount, currency, value date and reference PAY-2026-1105-25000 attached for the next control.
System response. The duplicate detection service confirms receipt and queues the instruction for comparison, and the hub records the validation result and updates the payment state to validated for the customer tracking view.
What can fail.
- The beneficiary BIC is invalid, so validation fails and the payment is rejected for repair.
- The value date falls on a currency holiday, so the payment is held until the next business day.
- A mandatory field is missing, so the payment waits in repair and the customer is asked to correct it.
Stage 5: Payment Hub Duplicate Detection
Incoming data. The duplicate detection service receives the validated instruction for USD 25,000 to Harbour Bank Singapore, with the debtor account, beneficiary account, amount, currency, value date and remittance reference INV-8841.
Processing logic. The service compares the instruction against payments sent in the last 24 hours on amount, beneficiary, account, reference and channel, using exact and fuzzy matching, and finds no earlier payment with the same details. The payment state remains validated and no funds move.
Outgoing message. The instruction is cleared as not a duplicate and passed to the account validation service with the debtor account, the amount and the reference attached, so the bank can confirm the debit account exists and can fund the payment.
System response. The account validation service confirms receipt, and the hub records the duplicate check result, updates the payment state to duplicate checked, and keeps the tracking view current for the treasurer.
What can fail.
- The instruction matches a payment sent an hour earlier, so it is held as a suspected duplicate.
- The duplicate database is unavailable, so the payment waits rather than being released unchecked.
- A near match with a different invoice reference is flagged for manual review by operations.
Stage 6: Core Banking
Incoming data. The core banking system receives the request to validate the debtor GBP account for the USD 25,000 payment, with the customer number, account number, value date and reference PAY-2026-1105-25000 attached.
Processing logic. Core banking confirms the account exists, belongs to the London corporate, is open and in good standing, and holds enough GBP to cover the USD 25,000 payment plus charges. The payment state moves to account validated, and the funds are earmarked but not yet debited.
Outgoing message. The account validation result, with the available balance and the earmarked amount, is returned to the payment hub, and the instruction is passed to enrichment with the confirmed debtor account and customer details attached.
System response. The hub records the validation result, updates the payment state to account validated, and tells the customer tracking view that the debit account is confirmed and the payment can continue to the next stage.
What can fail.
- The debtor account has insufficient funds, so the payment is rejected and the customer is notified.
- The debtor account is frozen, so the payment is held and operations must investigate before release.
- Core banking is unavailable, so the account check times out and the payment waits for retry.
Stage 7: Payment Hub Enrichment
Incoming data. The enrichment service receives the validated instruction for USD 25,000, with the debtor account, the beneficiary name and account, the Harbour Bank Singapore BIC, the value date and reference PAY-2026-1105-25000.
Processing logic. The service adds the debtor address and legal entity details, the beneficiary bank name and country, the charge rule for SHA, the cut off time and the end to end reference, using customer and reference data from the hub. The payment state becomes enriched and the ledger is untouched.
Outgoing message. The enriched instruction, now complete with debtor, creditor, bank, charge and reference data, is sent to the screening engine for sanctions, anti money laundering and fraud checks before any funds can move.
System response. The screening engine confirms receipt and queues the payment for checks, and the hub records the enrichment result and updates the payment state to enriched, ready for screening to begin.
What can fail.
- The beneficiary bank details are missing from the reference data, so enrichment cannot complete and the payment is held.
- The debtor address is incomplete, so the payment waits for the customer data to be corrected.
- The reference data service is down, so enrichment retries and the payment stays in queue.
Stage 8: Screening Engine
Incoming data. The screening engine receives the enriched instruction for USD 25,000, with the London debtor, the Singapore creditor, the banks, the countries, the purpose supplier payment and the invoice reference INV-8841.
Processing logic. The engine screens the debtor, creditor, banks and countries against sanctions lists, checks anti money laundering rules and fraud patterns, and scores the payment for unusual behaviour. No match is found, so the payment state moves to screened and the ledger remains unchanged.
Outgoing message. The engine returns a clear screening result to the hub, with the lists checked, the score and the clearance reference attached, and the payment is released for foreign exchange and routing to the next stage.
System response. The hub records the screening result, updates the payment state to screened, and forwards the instruction to the foreign exchange engine so the GBP debit can be converted into the USD 25,000 payment amount.
What can fail.
- A close name match to a sanctions entry holds the payment for manual review.
- A high fraud score blocks the payment and raises an alert for the fraud team.
- A screening system outage queues the payment until the engine is back online.
Stage 9: FX Pricing Engine
Incoming data. The foreign exchange engine receives the screened instruction, with the debtor GBP account, the USD 25,000 payment amount, the value date 5 November 2026 and reference PAY-2026-1105-25000, and the request to convert pounds into dollars.
Processing logic. The engine takes a live GBP to USD rate, applies the agreed customer margin, and calculates the GBP debit needed to deliver exactly USD 25,000, then locks the rate in a quote valid for fifteen minutes. The payment state moves to FX quoted and no ledger entry is posted yet.
Outgoing message. The locked quote, with the rate, the GBP debit amount, the USD 25,000 credit amount and the quote expiry, is returned to the hub, and the instruction is passed to routing with the conversion details attached.
System response. The hub accepts the quote, records the rate and the GBP amount, and updates the payment state to FX applied, so the customer tracking view shows the debit amount in pounds and the credit amount in dollars.
What can fail.
- The FX rate moves beyond the agreed tolerance before the quote is accepted, so a fresh quote is needed.
- The quote expires while the payment waits, so the hub must request a new rate before continuing.
- The FX engine is unavailable, so the payment is queued until pricing returns.
Stage 10: Routing Engine
Incoming data. The routing engine receives the screened and FX converted instruction for USD 25,000 to Harbour Bank Singapore, with the debtor and creditor banks, the currency, the value date and reference PAY-2026-1105-25000.
Processing logic. The engine checks SWIFT cut off times, correspondent relationships, nostro balances and costs, then selects the route through the Meridian Bank USD correspondent in New York to Harbour Bank Singapore. The payment state moves to routed and the ledger is still unchanged.
Outgoing message. The routed instruction is sent to correspondent selection with the chosen route, the settlement account, the charge bearer SHA and the value date attached, ready for the correspondent bank to be confirmed.
System response. Correspondent selection confirms it has the routed instruction, and the hub updates the payment state to routed, with the chosen path and the expected value date visible to operations and the customer.
What can fail.
- No correspondent holds enough USD liquidity, so the payment waits for funding.
- The SWIFT cut off time has passed, so the value date moves to the next business day.
- The chosen correspondent is offline and the engine must select an alternative route.
Stage 11: Correspondent Banking
Incoming data. Correspondent selection receives the routed instruction for USD 25,000, with the New York correspondent route, the Harbour Bank Singapore beneficiary bank, the settlement account and reference PAY-2026-1105-25000.
Processing logic. The service checks the nostro balance at the New York correspondent, confirms the relationship agreement is active, verifies the RMA authorisation for the next bank, and confirms the correspondent can settle on the value date. The payment state becomes correspondent selected and the nostro is earmarked.
Outgoing message. The confirmed correspondent chain, with the New York correspondent, the Harbour Bank Singapore beneficiary bank and the settlement account, is sent to message generation so the pacs.008 can be built for transmission.
System response. Message generation confirms it has the correspondent chain, and the hub updates the payment state to correspondent selected, with the nostro account and the settlement route recorded for operations and reconciliation.
What can fail.
- The nostro balance is too low at the correspondent, so the payment queues until treasury funds the account.
- The RMA authorisation for the next bank has expired, so the payment is held while a new RMA is requested.
- The relationship agreement with the correspondent is suspended, so an alternative correspondent must be found.
Stage 12: SWIFT Message Builder
Incoming data. The message builder receives the routed and confirmed instruction for USD 25,000 to Harbour Bank Singapore, with the full debtor, creditor, amount, currency, value date, charges and reference PAY-2026-1105-25000.
Processing logic. The builder creates a pacs.008 customer credit transfer, maps the enriched data into the ISO 20022 fields, adds the UETR and the end to end reference, and validates the message against CBPR+ rules. The payment state moves to message built and the ledger remains unchanged.
Outgoing message. The validated pacs.008 is sent to the SWIFT transmission gateway with the UETR, the debtor and creditor details, the USD 25,000 amount and the value date, ready to be signed and sent over the network.
System response. The transmission gateway confirms receipt of the pacs.008 and queues it for signing, and the hub updates the payment state to message built, with the UETR recorded so the customer can track the payment end to end.
What can fail.
- The pacs.008 fails CBPR+ validation because the creditor address is incomplete, so the message is rejected before sending.
- A mapping error leaves a mandatory field blank, so the message is returned to enrichment for correction.
- The UETR cannot be generated, so message creation stops and the payment waits for the service to recover.
Stage 13: SWIFT Gateway
Incoming data. The SWIFT gateway receives the signed pacs.008 for USD 25,000 to Harbour Bank Singapore, with the UETR, the debtor and creditor details, the value date and reference PAY-2026-1105-25000, ready for transmission.
Processing logic. The gateway signs the message, checks the RMA authorisation for the receiving bank, encrypts the payload, and transmits the pacs.008 over the SWIFT network to the New York correspondent and Harbour Bank Singapore. The payment state moves to sent and the ledger is still unchanged.
Outgoing message. The pacs.008 leaves the gateway for the correspondent bank in New York and the creditor agent in Singapore, and a copy of the sent message with its network reference is returned to the hub for tracking and audit.
System response. The SWIFT network confirms delivery of the pacs.008, the hub records the network reference and updates the payment state to sent, and the customer tracking view shows the payment has left Meridian Bank London.
What can fail.
- The SWIFT network is unavailable and the message queues for retry.
- The RMA authorisation for the receiver is missing, so the network blocks the message.
- A wrong BIC sends the message to the wrong bank and a recall is needed.
Stage 14: SWIFT Status Handler
Incoming data. The status handler receives a pacs.002 report from the New York correspondent for the USD 25,000 payment, with the UETR, reference PAY-2026-1105-25000 and the acceptance status code ACCP attached.
Processing logic. The handler matches the pacs.002 to the original pacs.008 by UETR and reference, reads the acceptance status, and records the correspondent acceptance time against the payment. The payment state moves to accepted and no ledger entry is posted at this stage.
Outgoing message. The acceptance is forwarded to the hub and to the customer tracking view, with the pacs.002 status, the acceptance time and the correspondent reference attached, so operations can see the payment is accepted downstream.
System response. The hub updates the payment state to accepted, confirms the correspondent has the instruction, and tells the tracking view that the payment is in transit to Harbour Bank Singapore for clearing and settlement.
What can fail.
- The pacs.002 reports a rejection, so the hub marks the payment rejected and alerts operations.
- The pacs.002 cannot be matched to any pacs.008, so it is held for investigation as an orphan status.
- No pacs.002 arrives within the expected window, so operations chase the correspondent for confirmation.
Stage 15: Clearing System
Incoming data. The clearing stage receives the payment instruction in Singapore, with the pacs.008, the USD 25,000 amount, the Harbour Bank Singapore creditor agent, the value date 5 November 2026 and reference PAY-2026-1105-25000.
Processing logic. The creditor agent validates the pacs.008, checks the creditor account, confirms the value date is a business day in Singapore, and prepares the entry for the local clearing cycle. The payment state moves to clearing and the ledger is not yet updated.
Outgoing message. The cleared instruction is passed to settlement with the USD 25,000 amount, the creditor account and the value date confirmed, ready for the final settlement posting between the correspondent and the creditor agent.
System response. The settlement function confirms the instruction is ready, the hub updates the payment state to clearing complete, and the tracking view shows the payment has cleared in Singapore and is ready for settlement.
What can fail.
- The local clearing system is closed for a public holiday in Singapore, so the payment waits until the next clearing cycle.
- The creditor account is frozen, so clearing cannot complete and the payment is held.
- A clearing file format error rejects the batch and the payment must be resubmitted.
Stage 16: Settlement Engine
Incoming data. The settlement engine receives the cleared instruction, with USD 25,000 to be settled between the New York correspondent and Harbour Bank Singapore on 5 November 2026 under reference PAY-2026-1105-25000.
Processing logic. The engine debits the Meridian Bank nostro account at the New York correspondent for USD 25,000 and credits the Harbour Bank Singapore settlement account for the same amount, then checks that both legs balance. The payment state moves to settled and the nostro balance falls by USD 25,000.
Outgoing message. The settlement confirmation, with the settlement reference and the balanced debit and credit legs, is sent to Harbour Bank Singapore and to the hub, and a pacs.002 status confirms settlement is complete.
System response. The hub receives the settlement confirmation, updates the payment state to settled, and the customer tracking view shows the funds have reached the beneficiary bank in Singapore and are ready for credit.
What can fail.
- The nostro account is overdrawn at settlement time, so the payment fails and must be retried after funding.
- A ledger posting error leaves the debit and credit unbalanced and the payment is held for reconciliation.
- The settlement system is down at the cut off and the value date slips.
Stage 17: Beneficiary Bank Core
Incoming data. Harbour Bank Singapore receives the settled funds and the pacs.008, with instructions to credit USD 25,000 to the supplier account on 5 November 2026 under reference PAY-2026-1105-25000 and invoice INV-8841.
Processing logic. The bank screens the incoming payment, checks the creditor account number and name, matches the remittance reference to the supplier account, and prepares the credit posting for the stated value date. The payment state moves to credit pending and the supplier account is checked before posting.
Outgoing message. The bank credits USD 25,000 to the supplier account, sends a credit advice to the supplier, and returns a pacs.002 status confirming the beneficiary has been credited to Meridian Bank London.
System response. Meridian Bank receives the completion status, marks the payment as completed, and the London customer sees the delivery confirmation in online banking with the full tracking history and the value date.
What can fail.
- The creditor account number does not match the account name, so the bank holds the funds for verification.
- The creditor account is closed, so the bank returns the payment with a pacs.004.
- A final sanctions check flags the payment and the credit is delayed for review.
Stage 18: General Ledger
Incoming data. The general ledger receives the completed payment record for USD 25,000, with the GBP debit amount, the FX rate, the nostro settlement legs, the fee of USD 25 and reference PAY-2026-1105-25000.
Processing logic. The ledger posts the customer debit in GBP, the nostro debit in USD, the fee income and the settlement entries, then checks that total debits equal total credits across the payment. The payment state moves to posted and the customer account balance now reflects the debit and the fee.
Outgoing message. The balanced ledger entries, with the payment reference, the value date and the account postings, are stored in the general ledger and passed to the notification service so the customer can be told the payment has been credited to the beneficiary.
System response. The notification service confirms it has the completed payment record, and the hub updates the payment state to posted, with the ledger balanced and the accounting ready for reconciliation at the end of the day.
What can fail.
- A posting error leaves the ledger unbalanced, so the entries are reversed and reposted by operations.
- The fee entry posts to the wrong income account, so a correction entry is needed before close of business.
- The ledger is closed for the day before the entries arrive, so they post on the next business day.
Stage 19: Notification Service
Incoming data. The notification service receives the completed payment record for USD 25,000, with the debtor and creditor details, the value date, the charges and reference PAY-2026-1105-25000, ready to tell the customer.
Processing logic. The service builds the customer confirmation message, the supplier credit advice and the operations alert, using the payment reference, the amount, the value date and the tracking history. The payment state moves to notified and the ledger stays balanced with no new entries.
Outgoing message. The confirmation is sent to the London corporate by online banking and email, the credit advice is sent to the Singapore supplier, and the status update is pushed to the customer tracking view.
System response. The channel confirms the customer has been notified, the supplier advice is delivered, and the hub updates the payment state to notified, with all parties informed and the payment ready for final reconciliation.
What can fail.
- The customer email address is invalid, so the confirmation bounces and the channel shows it instead.
- The notification service is down, so messages queue and are sent when the service returns.
- The supplier advice is sent to the wrong contact, so operations resend it to the correct address.
Stage 20: Reconciliation Engine
Incoming data. The reconciliation engine receives the posted payment record for USD 25,000, with the nostro debit, the settlement legs, the fee entry, the Harbour Bank statement lines and reference PAY-2026-1105-25000.
Processing logic. The engine matches the nostro debit to the New York correspondent statement, the settlement credit to the Harbour Bank statement, and the customer debit to the general ledger, checking amounts, value dates and references. All legs match, so the payment state moves to reconciled and the ledger is confirmed balanced.
Outgoing message. The matched reconciliation result, with the payment reference, the matched statement lines and the zero break amount, is stored in the reconciliation report and passed to the hub to close the payment.
System response. The hub marks the payment as closed and reconciled, the customer tracking view shows the final completed status, and the payment lifecycle ends with every ledger entry balanced and every statement line matched.
What can fail.
- The nostro statement shows a different amount, so a break is raised for operations to investigate.
- The Harbour Bank statement arrives late, so reconciliation waits until the statement is received.
- A value date mismatch between the ledger and the statement creates a break that must be resolved.