Follow the payment, message by message.

Using an app or a branch, the payer gives their bank an instruction: pay this person, at that bank, this amount. Nothing has moved yet — it is only a request.

Banks do not call each other one by one. They send payment messages to a shared clearing system that connects them all.

The message tells Nordbank exactly whose account to credit and with how much.

The customer instructs their bank to pay. A corporate typically sends a pain.001 file; a retail customer uses a banking channel that creates the same instruction internally.

The debtor agent converts the customer instruction into an interbank pacs.008 and submits it to the clearing and settlement mechanism.

The creditor agent receives the pacs.008 with full payment details so it can credit the right account.

The customer pays from an app or channel. From this moment the scheme's clock is running — the whole journey must finish within the scheme's time limit.

A pacs.008 flagged for the instant scheme is sent to the CSM, which immediately pushes it onward.

The CSM forwards the payment in real time and waits for the beneficiary bank's answer.

The pacs.002 positive status is the trigger for settlement and for both customers' account movements.

The ordering customer instructs Bank Alfa to pay a supplier banked at Cassia Bank in another country. Bank Alfa has no direct account relationship with Cassia — that is why correspondents exist.

In the serial method the payment instruction itself travels through the account chain. Meridian holds Bank Alfa's USD account (Bank Alfa's nostro), so Meridian can debit it.

The MT910 credit confirmation lets Cassia's reconciliation match expected funds against its nostro account movement.

Meridian forwards the payment instruction to the beneficiary bank with the full ordering and beneficiary details intact.

Same starting point as the serial method — the difference is how Bank Alfa chooses to route instruction and money.

The beneficiary bank learns the full payment details immediately — who is paying whom, how much, and why. But this message alone brings no money.

The MT202 COV moves the money along the account chain. Its sequence B repeats the underlying customer details so every bank in the chain can screen the real parties.

The credit advice tells Cassia the money side is complete. Now it has both halves: instruction and funds.

A corporate treasury sends a pain.001 with structured party and remittance data — the structure survives the whole journey because every hop speaks ISO 20022.

The interbank message travels with a Business Application Header and a UETR — the end-to-end reference every bank keeps unchanged, making the payment trackable.

The same UETR arrives at Cassia; anyone with the reference can see where the payment is in the chain.

Where the bilateral service reports a positive pacs.002, ACCC indicates that the creditor account was credited. Positive status reporting is service-dependent; a FINplus delivery acknowledgement alone does not prove customer credit.

Asha Traders asks Bank Alfa to pay one supplier. The pain.001 is a customer instruction, not an interbank payment and not proof that funds moved.

A pain.002 says the instruction passed the reported checks and was accepted for processing. It does not say the supplier has been credited; banks choose which lifecycle statuses their service reports.

Where the service provides it, a camt.054 reports the booked debit promptly and carries structured references for cash application. It reports an account entry; it does not create the entry.

Bank Alfa turns the accepted customer instruction into a pacs.008. The UETR, end-to-end reference, parties, agents, amounts, and remittance data identify the same business payment on the interbank leg.

Meridian forwards the serial customer credit transfer with the original UETR and structured payment data so Nordbank can match the instruction to the incoming value on its correspondent account.

Where the bilateral service provides a positive pacs.002, ACCC reports that the creditor account was credited against the original pacs.008. A transport acknowledgement and a business payment status are different signals.

If contracted, camt.052 gives Asha an intraday view of balances and entries, including the debit and its references. It is an interim report, not the final daily statement.

Bank Alfa sends the booked statement for the account. Treasury matches the camt.053 entry to its pain.001 transaction using the end-to-end and account-servicer references.

A corporate treasury sends a pain.001 with structured party and remittance data. The same starting point as a serial payment — what differs is how Bank Alfa routes the instruction and the money.

The creditor agent learns the full payment details immediately — who is paying whom, how much, and why — carried in structured fields under a Business Application Header. But this message alone brings no money.

The pacs.009 COV moves the money along the account chain. Its underlying-customer block repeats the debtor and creditor so every bank in the chain can screen the real parties, and it shares the same UETR as the pacs.008.

Asha Traders asks Bank Alfa to execute the supplier payment with an MT101. It is the legacy initiation request, not the bank-to-bank customer payment and not proof of execution.

Where contracted, MT900 confirms one booked debit on the serviced account. It is an account-entry advice, not a beneficiary-credit confirmation and not a substitute for payment status.

The MT103 carries the customer-payment instruction into the correspondent chain. In a serial route the instruction follows the account path used to settle the value.

The MT910 advises Nordbank that its account at Meridian was credited. Nordbank uses it to match the incoming value against the customer-payment instruction.

Meridian forwards the serial customer-payment message with the original references and party details so Nordbank can validate and apply the credit.

Where contracted, MT941 reports balances without the full transaction list. It is one legacy predecessor of the broader camt.052 account report.

MT942 reports account movements during the day. Treasury uses the original and account-servicer references to match the payment before the final statement arrives.

Bank Alfa sends the booked customer statement. Asha reconciles the MT940 entry to the original MT101 transaction and its own expected cash position.

Meridian's MT950 reports the entries on Bank Alfa's correspondent account. This bank-to-bank reconciliation is a different account perspective from the corporate's MT940.

A corporate treasury instructs Bank Alfa to send a high-value dollar payment to a beneficiary at another US bank. Nothing has moved yet — it is a request.

The sending bank submits the funds-transfer message to the Federal Reserve, which processes it the instant it arrives rather than batching it for later.

Fedwire tells the receiving bank the funds are on its Reserve account and final, with the details of whom to pay.

A corporate treasury asks Bank Alfa to pay a beneficiary at another CHIPS participant. Bank Alfa validates and screens it before submitting.

The payment joins the CHIPS system, which will hold it until it can be released against the participants' running net positions.

CHIPS tells the receiving participant the payment is released and final on the system's books, with the details of whom to credit.

Riya asks her bank to send a standard SEPA Credit Transfer (SCT) of EUR 900.00 to Arjun. A corporate would send a pain.001 file; a retail app creates the same instruction internally.

Bank Alfa converts Riya's instruction into an interbank pacs.008 and submits it into a STEP2-T processing cycle. STEP2-T is EBA CLEARING's pan-European retail automated clearing house (ACH).

STEP2-T forwards the pacs.008 with the full payment details to Nordbank so it can credit the right beneficiary account for Arjun.

The customer sends Bank Alba a file of euro credit transfers. This customer-to-bank file is separate from the interbank file Bank Alba later sends through its sponsor.

Bank Alba does not connect or settle directly with the CSM. It sends a sponsor-specific file or message envelope containing pacs.008 transactions and the control data agreed in their bilateral service.

The CSM sees Sponsor Bank as the submitting and settling direct participant. References still identify Bank Alba and the original transactions for reporting and reconciliation.

In this implementation, input credit file is Nordbank's local name for the inbound envelope carrying the pacs.008 transactions. It is not a universal EPC or ISO 20022 message name.

The creditor tells the debtor the amount and the due date in advance, so Riya can expect the debit and keep the account funded. This is a courtesy notice ahead of the pull, not the money movement itself.

Here is the mirror image of a credit transfer: the instruction starts at the payee. Asha Traders sends a pain.008 collection request to its own bank, Nordbank, to go and pull the funds from Riya's account.

Nordbank converts the customer collection into an interbank pacs.003 and submits it to the clearing and settlement mechanism, which will route it toward the debtor's bank to be collected on the due date.

Asha Traders instructs Nordbank to collect the invoice. A corporate creditor sends a pain.008 collection request naming the debtor and referencing the signed mandate.

The creditor bank converts the instruction into an interbank pacs.003 collection and submits it to the clearing and settlement mechanism for routing to Bank Alfa.

Riya enters Arjun's name and IBAN and asks to send EUR 480.00 instantly. Nothing has moved yet — this is only the instruction being prepared for a check.

Verification of Payee (VoP) checks the payee name against the IBAN before the payment is authorised. Bank Alfa asks Nordbank whether the name Riya typed matches the account. This is identity verification, not a movement of money.

Nordbank compares the submitted name with the name registered on the account and answers MATCH, CLOSE MATCH, or NO MATCH. It is a warning signal for the payer, separate from sanctions screening and from any movement of funds.

The result is MATCH, so Bank Alfa tells Riya the name fits the account and she confirms the payment. VoP is a fraud and misdirection control that runs before money moves; the decision to proceed stays with the payer.

Bank Alfa converts the confirmed instruction into an interbank pacs.008 flagged for the instant scheme and sends it to TIPS, the instant settlement infrastructure.

Bank Alfa's payments desk sends a high-value interbank payment (a pacs.009) to TARGET2, which processes it the instant it arrives rather than batching it for a later cycle. Nothing has moved yet — it is an instruction.

TARGET2 tells the receiving bank that the funds are on its account at the central bank and are final, with the details of the payment it needs to apply.

Riya asks Bank Alfa to send EUR 480.00 to Arjun through its customer channel. This is not a pacs.008 yet: Bank Alfa must validate the request and create the inter-PSP instruction.

Bank Alfa sends the inter-PSP instruction. TIPS validates it and, once accepted, reserves the amount on the originator participant's TIPS dedicated cash account while the beneficiary side decides.

Nordbank validates the account and answers positively. This positive pacs.002 is what authorises TIPS to move central bank money between the two accounts.

Bank Alfa must pay a high-value sterling obligation — the completion monies on a property purchase — to Nordbank, so it sends an interbank payment (a pacs.008) into CHAPS. Since the ISO 20022 migration on 19 June 2023 the message carries richer structured data, including the Purpose Code and Legal Entity Identifier (LEI). Nothing has moved yet — it is an instruction.

CHAPS tells the receiving bank that the funds are on its settlement account at the Bank of England and are final, with the payment details — including the Purpose Code and LEI — it needs to apply.

On a Sunday evening Riya opens her banking app and instructs Bank Alfa to send GBP 500.00 to Arjun at Nordbank. Faster Payments runs 24/7, so time of day does not matter. Nothing has moved yet — this is only a request.

Bank Alfa submits the payment to the central Faster Payments infrastructure, which routes it to Nordbank immediately. This real-time clearing leg carries the instruction — it does not move central bank money.

Faster Payments forwards the payment to Nordbank in real time and expects a fast answer. The message tells Nordbank exactly whose account to credit and with how much.

On Day 1 the employer sends its payroll file to Bacs through its bank. This is an instruction to pay, not money moving — it enters the fixed three-working-day cycle. Bacs is a batch system, so the file waits its turn.

On day one Asha Traders sends its collection file to Bacs through its own bank, Nordbank. The file lists Riya's bill of GBP 90.00 against her mandate. This is an instruction to collect — no money has moved yet.

Riya asks Bank Alfa to send USD 300.00 to Arjun on a public holiday. FedNow runs 24/7/365, so there is no cut-off or waiting for a business day — but nothing has moved yet, this is only a request.

The sending bank sends the payment message to the FedNow Service, which processes it the instant it arrives rather than batching it. The message asks for settlement; it does not itself carry the money.

FedNow asks the receiving bank whether it can apply the payment to Arjun's account. Nordbank checks the account and answers positively — this confirmation is what lets settlement proceed.

FedNow sends the sending bank a positive payment status after recording settlement. This pacs.002 is evidence of the service outcome; it reports the settlement and does not move the money itself.

The employer instructs its bank to pay wages. It sends a payroll ACH file of credit entries to Bank Alfa, its Originating Depository Financial Institution (ODFI). This is an instruction, not money.

The ODFI sends the batched file to one of the two ACH Operators — the Federal Reserve or The Clearing House. Nacha writes and enforces the rules, but the operator is the party that processes the entries.

Riya tells her bank to send USD 250.00 to Arjun right now, at night. RTP is push-only: money only moves because the sender chooses to send it — you cannot pull funds from someone else's account.

Bank Alfa screens and validates the payment, then submits an RTP credit transfer to the network. RTP is open 24/7/365, so there is no cut-off to wait for — the request is processed the moment it arrives.

RTP uses Bank Alfa's balance in the prefunded joint account at the Federal Reserve Bank of New York and asks Nordbank whether it will make the funds available to Arjun. Banks must keep that prefunded balance topped up for this to work.

Nordbank answers that it will credit Arjun immediately. A receiving institution on RTP must make the money available to the recipient right away, not hold it for later.

On its customer Asha Traders' behalf, Bank Alfa sends the RTGS message to the Reserve Bank of India to move INR 5,00,000.00 to a supplier account at Nordbank. This is above the INR 2,00,000 minimum for RTGS. Nothing has moved yet — it is a request.

The Reserve Bank tells Nordbank the funds are on its settlement account and final, with the details of the beneficiary to be paid.

Riya tells her bank to send INR 15,000.00 to Arjun by NEFT, giving his account number and the beneficiary bank's IFSC so the payment can be routed nationwide.

Bank Alfa forwards the queued transfer to the NEFT system so it joins the batch of payments being collected for the current half-hourly settlement cycle.

The NEFT system passes the transfer details on to Nordbank so it knows which account to credit and for how much once the batch has settled.

Riya sends INR 3,000 late at night from her banking app, addressing Arjun by his mobile number and MMID (Mobile Money Identifier) instead of an account number and IFSC.

In real time the remitter bank sends the transfer to NPCI's IMPS switch, which resolves the mobile number and MMID to the right beneficiary bank and forwards it in seconds.

The switch relays the beneficiary bank's positive response back to Bank Alfa, which tells Riya the payment is complete — this all happens within seconds of her instruction.

Riya scans Arjun's QR or types his Virtual Payment Address (VPA / UPI ID), e.g. arjun@bankalfa. She pays a short handle, not a bank account number, so account details stay private.

The NPCI switch looks up the VPA behind the scenes and maps arjun@bankalfa to Arjun's real account at Nordbank, then routes the pay request. The account number is resolved by the network, never revealed to Riya.

Asha Traders hands the NACH Debit collection for Riya's EMI to Nordbank, its sponsor bank. This is an instruction to collect — no money has moved yet, and each item names the mandate that authorises it.

Nordbank groups Riya's item with many other collections and presents them into a NACH batch cycle at NPCI. NACH works in scheduled batches, not instantly, so the item waits for its cycle.

The remitter — a resident individual — asks Ganga Bank to remit INR 3,34,000 as USD to a friend's account in the US, and completes Form A2, the FEMA declaration naming the purpose of the transfer (here, a gift to a friend) and confirming the funds are the remitter's own.

Liberty Union holds Ganga Bank's USD account (Ganga Bank's nostro), so the interbank MT103 goes there. Because the customer instructed in INR but the interbank leg settles in USD, the message carries both: field 32A is the settled currency and amount (USD 4,000.00), field 33B is the originally instructed currency and amount (INR 3,34,000.00), and field 36 is the exchange rate Ganga Bank applied to convert between them (83.50).

Liberty Union forwards the payment instruction to the beneficiary's bank with the full ordering and beneficiary details intact — including the remitter's declared purpose, carried in the remittance information field.

The paying bank sends its high-value obligation to RITS, which processes it the instant it arrives rather than batching it for a later netting cycle. Nothing has settled yet — this is an instruction.

RITS confirms to the receiving bank that the funds are on its ESA and the settlement is final, with the details of the incoming payment.

Riya sends AUD 400.00 late at night and only needs Arjun's PayID — his mobile number. She never sees or types a BSB or account number, because the PayID resolves to his account for her.

The New Payments Platform looks up Arjun's PayID (his mobile number) and returns the account it points to at Nordbank, so the payment can be addressed without sharing a BSB or account number.

Bank Alfa sends a high-value Singapore-dollar payment instruction to MEPS+, the MAS Electronic Payment System, to pay Nordbank. This is a message — nothing has moved yet.

MEPS+ confirms to Nordbank that the funds are on its RTGS account at MAS and final, with the details of the interbank obligation now discharged.

On a Saturday Riya opens her banking app and instructs Bank Alfa to send SGD 500.00 to Arjun at Nordbank using FAST. FAST runs 24/7, so the weekend does not matter. Nothing has moved yet — this is only a request.

SACH forwards the cleared payment to Nordbank almost instantly and expects a fast answer. The message tells Nordbank exactly whose account to credit and with how much — it carries instructions, not the cash itself.

Riya scans Arjun's PayNow QR or types his mobile number in her banking app. She pays to an identifier she can remember, and never has to see or type his bank account number.

The PayNow directory looks up the mobile number and returns which bank and account it belongs to. The proxy points at a real account at Nordbank without ever exposing that account number to Riya.

The app shows the name registered against the proxy so Riya can check she is paying the right person before releasing the money. Confirming the name is her defence against a mistyped number.

Bank Alfa sends the payment instruction into HKD CHATS, the Hong Kong dollar real-time gross settlement system. CHATS also clears USD, RMB, and EUR, but this payment runs on the HKD system. Nothing has moved yet — it is a message.

CHATS tells Nordbank the funds are on its settlement account and settled, with the details of whom to pay. This is information, not the money itself.

Riya asks Bank Alfa to send HKD 600.00 to Arjun using his mobile number or FPS ID — a proxy address. She never has to know or type his account number, and FPS runs around the clock, so this works at night.

The Faster Payment System looks up the mobile number or FPS ID in its addressing directory and finds it points to Arjun's account at Nordbank. Only the mapping travels here — this message carries no money.

Bank Alfa sends a real-time gross settlement (RTGS) funds-transfer message for a high-value yen obligation to Nordbank. This is an instruction — the money has not moved yet.

BOJ-NET confirms to Nordbank that the funds are on its current account at the Bank of Japan and the settlement is final, with the details of the payment.

Riya asks Bank Alfa to pay Arjun by a domestic credit transfer. The instruction is a request to move money; on its own it carries no funds.

Bank Alfa submits the transfer to the Zengin System, the interbank clearing network run by Zengin-Net, which routes the details on to the receiving bank.

The sending bank transmits its SIC payment order to SIX Interbank Clearing, which operates the system on behalf of the SNB. This is an instruction — no money has moved yet.

SIC advises the receiving bank that the funds are final on its SNB sight deposit account, with the details of the payment it now needs to book to its customer.

Riya types Arjun's phone number as his Pix key and never has to know or share his account number. Pix works 24 hours a day, every day, with no fee to send.

Bank Alfa asks the DICT directory (the Transaction Accounts Identifier Directory) which account a Pix key points to. DICT answers with Arjun's account at Nordbank.

The sending bank submits a Reserve Transfer System message to move a high-value interbank obligation to Nordbank. Nothing has moved yet — it is a request, not the money.

The STR asks the Banco Central do Brasil whether Bank Alfa's reserve account holds the funds now — an RTGS rail will not create reserves a bank does not have.

The STR tells the receiving bank the reals are on its reserve account at the BCB and final, with the details it needs to book the funds.

Riya asks Bank Alfa to send MXN 2,000.00 to Arjun, addressing the destination account by its CLABE — the 18-digit interbank account number that identifies the bank and the account. Nothing has moved yet; this is a request.

Bank Alfa sends the payment order to SPEI, which verifies the message and checks the sending bank's digital signature. SPEI processes each order individually as it arrives rather than collecting orders into batches.

The sending bank submits a high-value wire to Lynx as an ISO 20022 message, so rich remittance data travels with the payment. Nothing has settled yet — this is the instruction.

Lynx confirms to the receiving bank that the payment has settled with finality in central-bank money, with the ISO 20022 details of the payment it now holds.

Riya types Arjun's email address in Bank Alfa's online banking and enters CAD 200.00. She never asks for his account number — the alias is enough to address the payment.

Because Arjun is not using Autodeposit in this path, Interac sends an email or text notification with a link into participating online banking. The notification announces the transfer; it does not carry money or prove that Arjun has deposited it.

Arjun follows the notification, signs in to a participating financial institution, answers the security question where required, and chooses an account. With Autodeposit, this manual claim step is skipped and the designated account is credited automatically.

Interac tells Riya that Arjun deposited the transfer and tells Arjun that the deposit completed. These notifications report the customer outcome; the banks' separate interbank settlement is still to follow.

Asha Traders, a customer of Bank Alfa, is paying a supplier banked at Nordbank. Bank Alfa generates a UETR — a 36-character unique end-to-end transaction reference — embeds it in the MT103, and sends the instruction to its USD correspondent, Meridian Bank, which holds Bank Alfa's nostro account.

Keyed to that UETR, Bank Alfa writes the first status to the cloud-based gpi Tracker. From this moment the payment can be followed end to end, unlike an opaque legacy correspondent chain where the originator saw nothing after sending.

Meridian passes the payment instruction on to the beneficiary bank, Nordbank, with the ordering and beneficiary details intact and the same UETR carried through — the tracking key stays constant along the whole chain.

As it processes the payment, Meridian posts its own status against the UETR to the Tracker, adding to a continuous status trail that Bank Alfa can see in near real time.

Nordbank sends a gpi confirmation of credit against the UETR to the Tracker, closing the trail. Bank Alfa and Asha Traders can now see end-to-end status and proof that the supplier was paid — the transparency gpi is built to deliver.

The instruction identifies the beneficiary, amount, currency and requested date. It does not yet choose the next SWIFT hop or prove that the bank can settle USD to Cassia.

The lack of direct RMA with Cassia is not bypassed. Bank Alfa sends to Meridian because that bilateral hop is authorized and Meridian is the agreed account and routing provider for USD.

Meridian sends the payment to Cassia under their authorized relationship, preserving the payment references and party information needed for validation and reconciliation.

Bank Alfa is an indirect participant abroad: it cannot submit to CIPS itself, so it sends the renminbi payment instruction for Asha Traders to Cassia Bank, the onshore CIPS direct participant it reaches the system through.

• DR Asha Traders' account at Bank Alfa — CNY 500,000.00

As a direct participant, Cassia submits the payment through its supported CIPS connectivity and message profile. The precise channel and implementation version are participant arrangements, so this flow does not label a proprietary CIPS instruction as a universal ISO message.

With the obligation settled onshore, CIPS delivers the payment details to Nordbank, the supplier's bank in China, so it knows exactly what to credit and to whom.

Asha Traders owes a supplier in another African country the equivalent of USD 20,000.00 for imported goods, and instructs Bank Alfa to pay in Asha's own local currency (local currency A) — no need to first buy a hard currency such as US dollars.

The buyer's local bank passes the validated instruction up to its own central bank, Central Bank A, which is the participant that connects the country's banks into PAPSS.

Central Bank A hands the cross-border instruction to PAPSS, the shared switch that links the participating African central banks so a payment can cross a border without leaving the continent's own systems.

Once validated, PAPSS forwards the instruction to the supplier's central bank, Central Bank B, which will route it down to the supplier's local bank — the message crosses the border, the money does not yet.

The supplier's central bank passes the instruction to the supplier's own local bank, Nordbank, which holds the supplier's account and will make the actual payment.

Asha Traders is paying a supplier in another Arab country. Bank Alfa, a Buna participant, sends the cross-border payment to Buna in one supported currency — here US dollars. The message asks for value to move; it does not carry the money itself.

With settlement complete and final across the Buna accounts, Buna passes the payment details to Nordbank, the beneficiary bank, so it knows the funds are theirs and whom to pay.

Maya taps her card for a EUR 42.50 catering order. The terminal reads the chip or contactless data defined by EMV (the chip-card standard maintained by EMVCo) — including a one-time cryptogram that proves a real card was present.

The terminal packs the card data, amount and merchant details into an authorization request — a 0100 message in ISO 8583, the card industry's messaging standard — and sends it to Meridian Bank, the acquirer that serves Demo Coffee.

The acquirer checks the merchant is one of its own and the message is well formed, then forwards the request into the card network. The acquirer cannot approve — only the card's issuer can say yes.

The network reads the bank identification number (BIN) — the opening digits of the card number — recognises Bank Alfa as the issuer, and delivers the request to it.

The issuer answers with a 0110 response carrying an approval and an authorisation code — a short reference that will later tie the clearing record back to this exact approval.

The network sends the response back along the same path it came. Request out, response back — one conversation, a few seconds end to end.

Meridian Bank passes the approval to the terminal. Maya sees 'approved'; Demo Coffee stores the authorisation code with the sale for tonight's clearing batch.

At end of day the terminal sends its captured sales — each with its authorisation code — to Meridian Bank. Until this capture, Maya's EUR 42.50 exists only as an approval and a hold.

The acquirer turns each captured sale into a clearing record and presents it to the network — the presentment. Each record references its authorisation so the issuer can match it to the hold it placed.

Maya's card statement shows Demo Coffee Ltd, EUR 42.50, now booked. Demo Coffee's acquiring statement shows the payout and the fees taken. Both sides can reconcile the same sale from their own end.

Maya tells Bank Alfa she does not recognise the EUR 42.50 booking on her statement. The issuer records the claim and, for many claim types, first asks whether she has tried to resolve it with the merchant directly.

The issuer sends a chargeback record into the network carrying a reason code — the claim's category, such as 'transaction not recognised' or 'goods not received'. The reason code fixes what evidence can answer it. Many issuers also re-credit the cardholder provisionally while the case runs.

The network checks the chargeback is validly formed — reason code allowed, raised within the time limit its rules set — and delivers it to the acquirer that presented the original sale.

The merchant answers the reason code with proof: the signed receipt, the terminal's EMV chip data showing the card was present, and the catering delivery note. Evidence that does not address the reason code does not count, however thick the file.

The acquirer sends the case back through the network as a representment — literally a second presentment of the sale, now with evidence attached — asserting the original charge was valid.

The network checks the representment is validly formed and passes it — evidence attached — to the issuer that raised the original chargeback.

Maya authorises on the device with a fingerprint or face check — the on-device strong customer authentication — and the wallet presents the DPAN plus a one-time cryptogram for this EUR 42.50 order, never the real card number.

Demo Coffee's terminal packs the DPAN, cryptogram, amount and merchant details into an authorisation request and sends it to Meridian Bank, its acquirer. The merchant only ever handles the token, not Maya's PAN.

The acquirer forwards the tokenised authorisation request into the card network so it can be detokenised and routed on to the right issuer.

With the real PAN restored, Cardnet routes the authorisation request to Bank Alfa, the account's actual issuer.

The issuer checks the real card account — is it open, do funds cover EUR 42.50, does the risk score pass — and answers with an approval and an authorisation code, sent back through Cardnet.

Instead of typing card details, Maya chooses to pay by bank. She gives Larkpay consent to start a single payment of EUR 42.50 from her account — consent is for this one payment, not open-ended access.

As a payment initiation service provider, Larkpay does not hold Maya's money. It calls Bank Alfa's open-banking API — the account servicer, or ASPSP — to set up the credit transfer Maya consented to.

Maya approves the payment directly with Bank Alfa — in its app or via a redirect — proving it is really her. Larkpay never sees her banking credentials; it only learns whether authentication succeeded.

The initiated payment becomes an ordinary interbank SEPA Instant credit transfer. Bank Alfa submits a pacs.008 to the clearing and settlement mechanism, addressed to Northstar Bank. Open banking started the payment; the SEPA rails carry it.

Instead of pulling by direct debit, the creditor asks to be paid. It submits a pain.013 request for EUR 120.00 with an invoice reference and a due date through Northstar Bank, its bank.

The Request-to-Pay service is a messaging layer, not a money mover. It carries the request from the creditor's side towards the debtor's bank; no funds move at this stage.

The service delivers the request to Bank Alfa, which presents it to Maya in her banking app — showing who is asking, how much, and by when.

A pain.014 response travels back to tell Example Supplies that Maya accepted and payment is coming. The response answers the request; it is not itself the money.

Acceptance triggers an ordinary payment. Bank Alfa debits Maya and submits a SEPA Instant credit transfer (a pacs.008) to Northstar Bank — the request has become a normal push payment.

• DR Maya Chen's current account at Bank Alfa — EUR 120.00

Both banks send matching settlement instructions for their agreed EUR/USD trade. CLS pairs the two sides — Bank Alfa is due to deliver euros and receive dollars, Northstar the reverse — and takes the pair in for settlement.

Asha pays a paper cheque into Northstar, her collecting bank, at a branch or through the mobile app. The cheque is an instruction from Demo Trading to its bank, Bank Alfa, to pay Asha.

Northstar sends the cheque image and its data into the image-exchange system, which routes it to Bank Alfa as the drawee. The image is the legal presentment — the paper never moves between the banks.

The paying customer tells its bank to pay a beneficiary at Northstar Bank. This is an instruction in commercial bank money — nothing has settled yet, and the customer never touches the wholesale CBDC directly.