700 Questions Learners Ask

Start with domestic payments first, before you touch cross border topics. That is the advice practitioners like give to every beginner, and it works because domestic payments are simpler, faster to observe, and easier to test against your own experience. Open your own bank app and trace what happens when you pay a bill, send money to a friend, or receive your salary. Ask what instruction you gave, who moved the money, when it settled, and what record was left behind. That everyday observation is your first textbook.

Next, build the core vocabulary in layers. First learn what a payment is, the difference between a payment and a transfer, and the difference between a payment instruction and settlement. Then learn the main instruments: cash, cards, credit transfers, direct debits, and instant payments. Then learn the ecosystem: who the debtor, creditor, debtor agent, and creditor agent are, what a clearing system does, and what a settlement system does. Do not memorise message formats at this stage. Formats make sense only after the business flow makes sense.

Finally, learn by working through real flows end to end. Pick one flow, such as a salary credit transfer or a card purchase, and follow it from initiation to clearing to settlement to reconciliation. Read one scheme rulebook section at a time, watch how exceptions are handled, and practise explaining the flow in plain language to someone else. If you can explain why a payment failed and what should happen next, you understand it. Add SWIFT, ISO 20022, and cross border topics only after the domestic foundation is solid.

A payment is the transfer of value from one party to another in order to settle an obligation. When you buy a coffee, pay rent, send a salary, or settle a supplier invoice, you are making a payment. The obligation can come from a purchase, a loan, a tax, a salary agreement, or any commitment where one party owes value to another. The payment discharges that obligation, fully or partly, and creates a record that the debt has been reduced or cleared.

In a modern banking context, a payment almost always involves accounts held with regulated institutions and a set of instructions that tell those institutions what to move, from whom, to whom, and for what reason. The instructions travel as a payment message, while the actual value moves through accounts and settlement systems. A payment can be made in cash, by card, by cheque, by direct debit, or by an electronic transfer, but in every case the same core elements are present. There is a payer who owes, a payee who is owed, an amount, a currency, a value date, and a reason or reference that links the payment to the underlying business event.

Understanding payments this way helps you avoid a common mistake, which is to treat every money movement as the same thing. A salary payment, a supplier payment, a refund, and a loan repayment may look similar on a bank statement, but they carry different business meanings, different regulatory expectations, and different risks. Always ask what obligation is being settled, who bears the risk if the payment fails, and what evidence exists that the obligation was discharged. Those three questions shape how payment products are designed, how exceptions are handled, and how messages are structured.

Payments can be classified in several useful ways, and a good analyst uses more than one classification at a time. By instrument, the main types are cash, cheques, payment cards, credit transfers, direct debits, and electronic money or wallet payments. Cash settles immediately but leaves no electronic trail. A cheque is a written instruction to a bank to pay a named person. A card payment lets a payer pay at a shop or online through a card scheme. A credit transfer pushes money from payer to payee. A direct debit pulls money from the payer under a prior mandate. Each instrument has a different speed, cost, risk, and information profile.

By direction of initiation, payments split into push and pull. In a push payment, the payer starts the movement, as with a credit transfer or an instant payment. In a pull payment, the payee starts the collection, as with a direct debit or a recurring card payment. Push gives the payer control over timing and amount. Pull is efficient for recurring collections but needs a mandate, pre-notification, and refund rights to protect the payer.

By geography and value, payments split into domestic and cross border, and into retail and wholesale or high value. Domestic payments move within one country and one currency, often through instant or batch systems. Cross border payments cross countries, currencies, and often several intermediary banks. Retail payments are many, small, and standardised. Wholesale payments are fewer, larger, and often settle individually in central bank money. When you analyse a payment, name its instrument, its push or pull nature, its geography, and its value band, because those four facts decide its clearing path, its settlement timing, and its failure modes.

A transfer is a broader term than a payment. Every payment involves a transfer of value, but not every transfer is a payment. When you move money from your own savings account to your own current account, that is a transfer, but it settles no obligation to another person. When a bank moves funds between its own internal accounts for liquidity management, that is also a transfer, not a payment to a customer. The word payment implies a payer, a payee, and an underlying reason for the movement, such as goods received, services delivered, or a debt that is due.

This distinction matters in payment systems because the rules, the messages, and the controls are different. A customer payment such as an MT103 or a pacs.008 carries details about the debtor and creditor, remittance information, and charges, because the receiving party needs to know why the money arrived and how to reconcile it. An internal transfer or a bank to bank cover payment such as an MT202 or a pacs.009 carries different information, because the business purpose is different. If you label a movement incorrectly, downstream systems may apply the wrong screening, the wrong accounting, or the wrong reconciliation logic.

In daily banking work you will also meet the phrase funds transfer, which is often used loosely to mean any electronic movement of money. A business analyst should be precise even when others are loose. Ask whether the movement settles a third party obligation, whether it is between accounts of the same legal owner, and whether it is part of a larger payment chain. The answers decide which message type is correct, which fields are mandatory, and which parties need to be notified. Precision here prevents misrouted payments, failed reconciliations, and audit findings later.

At the centre of every payment are four parties, known as the four-corner model. The debtor is the party who owes the money, for example a buyer or an employer. The creditor is the party who is owed the money, for example a seller or an employee. The debtor agent is the debtor bank, which holds the debtor account and executes the instruction. The creditor agent is the creditor bank, which holds the creditor account and credits the beneficiary.

Around those four corners sit several other players. Intermediary or correspondent banks sit between the debtor agent and the creditor agent when the two banks have no direct relationship, especially in cross border payments. Clearing systems net and route payment instructions between banks. Settlement systems, usually operated by a central bank, move value between banks so the payment becomes final. Card schemes, payment service providers, and fintechs may also take part, for example by initiating the payment, converting currency, or providing the customer interface.

Why does this matter for a learner? Because each player has different duties, different risks, and different information needs. The debtor agent must validate the instruction, check funds, and screen the payment. The creditor agent must identify the beneficiary account and reconcile the credit. An intermediary must forward the instruction accurately and manage its own liquidity. When a payment fails, the first diagnostic step is to ask which player holds the money now, which player has the next action, and which player owes an explanation to the customer. If you can name the players and their duties, you can trace almost any payment problem.

A payment rail is the infrastructure that carries a payment from one party to another. Think of it like a railway track. The train is the payment instruction, and the rail is the set of systems, rules, and connections that let the train reach its destination safely. A rail includes the network that moves the message, the clearing system that exchanges instructions between banks, the settlement system that moves value between banks, and the scheme rules that define cut off times, value dates, and liability when something goes wrong.

Common examples help make this concrete. In India, UPI, IMPS, NEFT, and RTGS are different rails with different speeds, limits, and settlement models. In the United States, Fedwire, ACH, and FedNow are separate rails. In Europe, SEPA Instant and TARGET2 serve different needs. Card rails are another family, where Visa and Mastercard networks carry authorisation and clearing messages between acquirers and issuers. SWIFT is not a rail in the settlement sense, because it carries messages, not value. It connects banks so they can instruct each other, but the value moves through correspondent accounts or settlement systems.

For a business analyst, the rail decides almost everything about the customer experience. It decides how fast the money arrives, how much the payment costs, what data can travel with it, what happens on a weekend or a holiday, and how failures and returns are handled. When you document a payment product, always name the rail, its settlement timing, its operating hours, its amount limits, and its message format. A payment that is technically correct but sent on the wrong rail can arrive late, cost too much, or fail reconciliation, and the customer will experience that as a failed payment.

A payment system moves value. A messaging system moves information about value. That single distinction explains most of the confusion beginners face in payments, and it is the key to understanding SWIFT, ISO 20022, and correspondent banking.

A payment system, such as a real time gross settlement system or an instant payment system, holds accounts and settles obligations between its participants. When a payment settles in such a system, central bank money or commercial bank money actually moves, and the payment becomes final. Examples include TARGET2 in Europe, Fedwire in the United States, and RTGS in India. These systems have settlement accounts, liquidity rules, and finality rules, and they carry settlement risk if a participant fails before settlement.

A messaging system, such as SWIFT, carries instructions and information between banks, but it holds no accounts and moves no money itself. When a bank sends an MT103 over SWIFT, it is telling the receiving bank to pay a beneficiary. The actual value moves separately, through correspondent accounts held between banks or through a settlement system. SWIFT also carries balance statements, payment status updates, and investigation messages, all without settling anything. ISO 20022 is a messaging standard, not a system at all. It defines the format of the messages that travel over payment systems and messaging networks. If you remember that messages instruct and systems settle, you will read every payment flow correctly.

The four-corner model is the simplest complete picture of a payment, and it is the foundation for everything in cross border payments. It has four corners. The debtor is the party who owes money. The debtor agent is the debtor bank, which holds the debtor account. The creditor agent is the creditor bank, which holds the creditor account. The creditor is the party who is owed money. Money and instructions flow in a loop between these four parties: the debtor instructs the debtor agent, the debtor agent instructs the creditor agent, the creditor agent credits the creditor, and the creditor is informed that the payment has arrived.

The model is powerful because it separates the commercial relationship from the banking relationship. The debtor and creditor have a commercial deal, for example a sale of goods, but they may bank with different institutions in different countries. The debtor agent and creditor agent bridge that gap. Each agent owes duties to its own customer: the debtor agent must validate the instruction, check funds, apply screening, and execute on time, while the creditor agent must identify the correct beneficiary account, apply its own checks, and credit the funds with clear information.

When a payment crosses borders, the model grows. If the debtor agent and creditor agent have no direct account relationship, intermediary or correspondent banks are added between them, creating a chain. Each link in the chain is itself a small four-corner relationship, with its own instruction, its own charges, and its own risk. Cover payments, serial payments, and SWIFT gpi tracking all become easier to understand once you see them as extensions of this basic model. Learn the four corners first, then add intermediaries one at a time, and the whole cross border world stays manageable.

The payment lifecycle is the full journey from the moment a customer decides to pay to the moment the payment is finally reconciled and closed. It usually has six stages: initiation, validation, processing, clearing, settlement, and reconciliation, with exception handling running alongside every stage.

Initiation is where the customer gives the instruction, through a mobile app, a corporate portal, a file upload, or a branch. The instruction must capture the debtor, the creditor, the amount, the currency, the value date, and the reason for the payment. Validation follows. The debtor agent checks that the account exists, the funds are sufficient, the details are complete, the instruction is authorised, and the payment passes sanctions and fraud screening. If any check fails, the payment is rejected or held for review at this point.

Processing is where the bank converts the instruction into the correct message format, such as a pacs.008, or an MT103 before the CBPR+ migration, and decides the route: which rail, which intermediary, and which settlement method. Clearing is the exchange of that instruction between banks, and settlement is the actual movement of value between banks, usually in central bank money or through correspondent accounts. Reconciliation is the final stage, where the creditor agent matches the credit to the expected receipt, the debtor confirms the debit, and both sides close their books. If anything goes wrong at any stage, the payment enters exception handling: investigation, repair, return, or recall. A business analyst who can walk through all six stages, and name who acts at each one, can design, test, and troubleshoot almost any payment product.

A Business Analyst in payments sits between the business and the technology, and turns a payment need into a system that works reliably. The job starts with understanding the business problem in plain language. The analyst asks who the users are, what the payment must achieve, what can go wrong, and what success looks like, then writes that down so clearly that both business stakeholders and developers can agree on it.

From there the work splits into four core activities. First, process analysis: mapping the current payment flow end to end, from initiation to settlement to reconciliation, and finding the gaps, delays, and manual workarounds. Second, requirements: writing functional requirements, message specifications, field mappings, validation rules, and exception handling for systems such as payment hubs, SWIFT interfaces, and ISO 20022 migrations. Third, testing and delivery: writing test cases, running user acceptance testing with real payment scenarios, checking message formats field by field, and confirming that returns, recalls, and investigations work. Fourth, stakeholder management: running workshops, resolving disagreements between operations, compliance, and technology, and explaining complex payment concepts in simple terms.

What makes a payments BA different from a general BA is domain knowledge. You need to know the four-corner model, the difference between MT and MX messages, how cover and serial payments work, what sanctions screening does, and why a value date matters. You do not need to write code, but you do need to read a payment message, trace a payment through a hub, and explain to a developer exactly which field must change and why. The best payments BAs combine that domain depth with clear writing, careful testing, and the patience to chase a single failed payment through five banks until the root cause is found.

Money is anything widely accepted as a medium of exchange, a unit of account, and a store of value. It lets people trade without barter, price goods in a common unit, and hold purchasing power for later use. In modern economies money takes several forms, including physical cash, bank deposits, and electronic money held with regulated institutions. A payment is the act of moving money from one party to another to settle an obligation, such as buying goods, paying a salary, or repaying a loan. Every payment therefore transfers a claim on money rather than moving physical value in most cases. When you pay by card, for example, no cash changes hands. Instead, instructions travel between banks and schemes, balances in ledgers are updated, and settlement moves funds between accounts at a central bank or a correspondent bank. Understanding money matters for payments work because the form of money decides the rules. Cash settles instantly and finally, bank money moves through clearing and settlement systems, and electronic money is a claim on an issuer that must be redeemed. A Business Analyst who understands these differences can explain why some payments are instant, why others take days, and why finality, liquidity, and risk differ across payment types.

Base money, also called central bank money, is money created by a central bank. It consists of physical cash in circulation and the reserves that commercial banks hold in accounts at the central bank. It is the safest form of money in a currency because it is a direct claim on the central bank, which cannot default in its own currency. Bank money, also called commercial bank money, is money created by commercial banks when they make loans or credit customer accounts. When a bank approves a loan, it creates a deposit in the borrower account, and that deposit functions as money for everyday payments. Most money used in daily life is bank money, not base money. The two forms connect through settlement. When you pay someone at another bank, your bank settles the obligation using base money, usually reserves at the central bank, even though you paid with bank money. This is why central bank settlement systems sit at the heart of a payment system. If a bank fails, deposits may be at risk, subject to deposit protection limits, while base money remains a claim on the central bank. Analysts must know this distinction because it explains settlement finality, why banks hold reserves, and why central bank operated systems are treated as the safest settlement venue.

A bank account is a record held by a bank showing money owed to a customer or owed by a customer to the bank. A credit balance in a current or savings account means the bank owes that amount to the account holder, and the holder can instruct the bank to pay it to someone else. An overdrawn balance means the customer owes the bank. The account has an identifier, such as an account number, and is usually linked to a sort code, branch code, or IBAN so payments can be routed to it. Different account types serve different needs. Current accounts support frequent payments, salary credits, and direct debits. Savings accounts pay interest and encourage holding funds. Business accounts handle higher volumes, multiple users, and bulk payments. Some accounts are in foreign currency, and some are restricted, such as escrow or client money accounts. A bank account is not a box of cash. It is a claim recorded in the bank ledger. When a payment is made, the bank reduces the payer balance and, after clearing and settlement, the payee bank increases the payee balance. Account details, ownership, and status checks matter in payments because a wrong account number, a closed account, or a frozen account can cause a payment to fail or be returned.

A ledger is the authoritative record of balances and transactions for accounts in a financial system. Every bank, payment service provider, scheme, and merchant keeps ledgers, though the technology and format differ. A ledger records who owns what, how balances changed, and when each change happened. In payments, the ledger is the source of truth. A payment instruction may travel through many systems, but the ledger entries decide whether money has actually moved. For example, when a customer pays a supplier, the payer bank debits the payer account in its ledger and the payee bank credits the supplier account in its ledger. Settlement between the banks is recorded in a separate ledger at the central bank or clearing house. Modern ledgers must be accurate, complete, and auditable. Each entry has a date, an amount, a currency, a reference, and the accounts affected. Entries are normally never deleted. Corrections are made with reversing entries so the full history stays visible. Analysts work with ledgers when reconciling payments, investigating missing funds, and designing new products. A common failure is a payment that succeeds in a front end system but never posts to the ledger, or posts twice, which is why reconciliation and idempotency controls are essential.

Double-entry bookkeeping is the rule that every transaction is recorded as equal debits and credits across at least two accounts, so the books always balance. If money leaves one account, it must arrive in another account. A payment of 100 from a customer to a merchant is recorded as a debit of 100 to the customer account and a credit of 100 to the merchant account. At the bank level, the same logic applies to settlement accounts, suspense accounts, and fee accounts. This method prevents many errors because an unbalanced entry is immediately visible, and it creates a clear audit trail for every movement of value. In payments systems, double entry appears in core banking ledgers, scheme settlement reports, and reconciliation processes. For example, when a card payment clears, the acquirer credits the merchant, debits a scheme settlement account, and records interchange and scheme fees as separate entries. Suspense accounts temporarily hold funds when the destination is unclear, and they must be cleared with matching entries. For a Business Analyst, double entry matters when writing requirements for posting logic, refund handling, fee calculation, and exception flows. A requirement that says credit the customer without saying which account to debit is incomplete, and that gap will surface as a reconciliation break in production.

A payment instruction is a message that tells a bank or payment provider to move money. A payment is the completed movement of money that follows from that instruction. The distinction matters because an instruction can be sent, received, validated, queued, rejected, or delayed, while the payment itself only exists once value has actually transferred and settled. For example, when you submit a transfer in a mobile banking app, you create a payment instruction. The bank checks the balance, validates the payee details, and screens the instruction for fraud and sanctions. Only after those checks does the bank debit your account and send the funds through a clearing system, completing the payment. In messaging systems such as SWIFT, the distinction is even sharper. A SWIFT MT103 is an instruction to pay, not the payment itself. The actual movement of funds happens through correspondent accounts or a settlement system. A Business Analyst must keep the two concepts separate when writing requirements, because the statuses, timelines, and failure modes differ. An instruction can fail validation before any money moves, while a payment can fail during settlement after the payer account has been debited, which creates a different exception and refund path.

A payment order is a formal instruction from an account holder to a bank or payment provider to transfer a specified amount to a specified beneficiary on specified terms. It is the legal and operational basis for the payment. The order normally includes the payer account, the payee name and account details, the amount and currency, the value date, the payment reference, and any charges instruction, such as who pays the fees. A payment order can be created through many channels, including a mobile app, internet banking, a branch form, a bulk file from a corporate customer, or an API call from a business system. Once accepted, the bank is obliged to execute the order as instructed, subject to funds, cut-off times, and compliance checks. If details are wrong or funds are missing, the order may be rejected or returned. Payment orders are also important in corporate and treasury operations, where a single file can contain thousands of orders for salaries, supplier payments, or tax payments. Each order is processed, validated, and tracked individually so failures can be identified and fixed. Analysts document payment order fields, validation rules, and statuses carefully, because a missing field or an unclear status can block straight-through processing and create manual work.

The value date is the date on which funds are considered to have been transferred for interest and availability purposes. It is the date from which the payee can use the money and the date from which the payer stops earning interest on it. The value date is not always the same as the date the instruction was sent or the date the payment was booked in the ledger. For example, a payment sent on Friday through a system that settles on Monday may carry a Monday value date, even though the payer account was debited on Friday. In foreign exchange and cross-border payments, the value date is agreed as part of the trade, commonly spot value, which is two business days after the deal date, or next day value. Value dates matter for interest calculation, liquidity management, and customer expectations. If a payment is late, the value date may be backdated to compensate the payee for lost interest. Banks also use value dates to manage intraday liquidity, because funds with a future value date are not yet available for onward payments. A Business Analyst must distinguish value date from booking date in requirements, because confusing the two causes wrong interest accruals, wrong availability messages, and reconciliation breaks between systems that record different dates for the same payment.

The booking date is the date on which a transaction is recorded, or posted, in the ledger of an account. It is the date that appears on an account statement next to the debit or credit. The booking date can differ from the value date and from the date the customer gave the instruction. For example, a card purchase made on Saturday may be booked on Monday when the clearing file arrives, even though the value date is Monday as well or the authorisation happened on Saturday. A salary payment sent on Friday may be booked on Friday in the payer account but booked on Monday in the payee account if settlement happens over the weekend. Booking dates matter for statements, reconciliation, and reporting. Customers expect transactions to appear in date order, and finance teams close books based on booking dates. If a payment is booked in the wrong period, monthly reports and tax records will be wrong. Systems often store several dates for one payment, including the instruction date, the booking date, the value date, and the settlement date. Analysts must define each date precisely in data models and reports, because a report built on booking date will show different totals from a report built on value date for the same set of payments near a month end.

A payment reference is a text field attached to a payment that explains what the payment is for, so the payee can identify and reconcile it. Common examples are an invoice number, a customer number, an order number, or a short description such as rent for March. The payer types the reference when making the payment, and the payee sees it on their statement or in their banking system. A good reference lets the payee match the incoming payment to an open invoice automatically, which is called auto-reconciliation. A missing or vague reference, such as payment or thanks, forces manual matching and delays the release of goods or services. References can be free text or structured. Some systems use a specific format, such as a structured creditor reference defined by ISO 11649, which includes a check digit so errors can be detected. Character limits vary by payment system, and special characters may be stripped or rejected. For a Business Analyst, the reference field is a common source of production issues. Requirements should state the maximum length, the allowed characters, whether the reference is mandatory, and how it flows from the front end through clearing to the payee statement without being truncated or lost.

An end-to-end reference is a unique identifier created by the originator of a payment and carried unchanged through every system involved, from the payer bank to the payee bank. Its purpose is to let every party identify the same payment across different systems, messages, and statements. Unlike a payment reference, which is a human readable note such as an invoice number, the end-to-end reference is a technical identifier used for tracking, investigation, and reconciliation. In ISO 20022 messages, the end-to-end reference sits in the payment identification block and is passed from the original instruction through clearing to the final credit. If a customer asks where their payment is, operations teams can search for the end-to-end reference in each system and see exactly where it stopped. This matters most in cross-border payments, where a payment may pass through several correspondent banks, each assigning its own internal reference. Without a shared end-to-end reference, tracing the payment becomes slow and error prone. Analysts should require that the end-to-end reference is generated once, never changed by intermediary systems, and stored in logs and reports so support teams can trace any payment quickly.

A unique transaction reference, often shortened to UTR, is a reference number assigned to a payment by the system that processes it, and it is unique within that system. It identifies one specific transaction and distinguishes it from every other transaction, even when the amount, payer, and payee are the same. Each payment system has its own version. In India, for example, the UTR for an RTGS or NEFT payment is a system generated number that the customer can quote when raising a query. In SWIFT payments, the UETR is a globally unique identifier added to track a payment end to end. Card systems use their own references, such as a retrieval reference number. The unique transaction reference is essential for investigations, returns, and reconciliation. If a payment goes missing or is duplicated, the reference proves which transaction is affected. It also prevents duplicate processing, because a system can reject a second instruction carrying the same reference as one already processed. Analysts must make sure requirements state who generates the reference, at which point in the flow, how it is stored, and how it is shown to customers and support teams, because a missing or reused reference makes payment investigations far harder.

A push payment is started by the payer, who sends money to the payee. A pull payment is started by the payee, who collects money from the payer account with the payer prior permission. A bank transfer, a salary payment, and a bill payment from a mobile app are push payments, because the payer decides when and how much to send. A direct debit, a card payment, and a cheque are pull payments, because the payee initiates the collection, relying on an earlier mandate or agreement. The difference matters for risk, control, and failure handling. In a push payment, the payer controls the timing and the amount, and the payment cannot happen without the payer acting. In a pull payment, the payer must trust the payee to collect the correct amount on the correct date, and the protection comes from the mandate, refund rights, and the ability to cancel. Pull payments can fail if the payer has insufficient funds, while push payments fail if the payer enters wrong details or lacks funds. Fraud patterns also differ. Push payment fraud tricks the payer into sending money to a criminal, while pull payment fraud misuses a mandate to collect money without permission. Analysts design different controls for each, including confirmation of payee for push payments and mandate checks and refund windows for pull payments.

A standing order is an instruction from an account holder to their bank to pay a fixed amount to the same payee at regular intervals, such as monthly rent of 500 paid on the first of each month. The payer sets up the order once, and the bank repeats it automatically until the payer cancels it or the end date is reached. Standing orders are push payments, because the payer bank sends the money on the payer instruction. They suit payments where the amount never changes, such as rent, a regular savings transfer, or a fixed subscription. The payer controls the order fully and can change the amount, the date, or the payee, or cancel it at any time. If funds are insufficient on the due date, the payment may fail or be retried depending on the bank policy, and the payee is not automatically told. Standing orders differ from direct debits, where the payee controls the collection and the amount can vary. For businesses, standing orders reduce manual work for regular fixed payments, but they need monitoring, because a forgotten standing order keeps paying after a contract ends. Analysts designing standing order features must cover setup, amendment, cancellation, failure handling, notifications, and the cut-off rules for same day changes.

A direct debit mandate is the authorisation a payer gives to a payee, and to the payer bank, allowing the payee to collect payments directly from the payer account. The mandate records the payer account details, the payee identity, a mandate reference, and the payer consent. Once the mandate is set up, the payee can collect varying amounts on varying dates, such as a monthly utility bill that changes with usage, without asking the payer each time. The payee must normally give advance notice before each collection, telling the payer the amount and the date. Direct debit schemes give the payer strong protection. In the United Kingdom, the Direct Debit Guarantee lets the payer claim an immediate refund from their bank if a collection is wrong, and the payer can cancel the mandate at any time. Mandates can be paper based or electronic, and they are stored by the payee, the payer bank, and sometimes a central scheme. If a mandate is missing, expired, or cancelled, the collection will be rejected. For a Business Analyst, mandates are a core data object. Requirements must cover mandate creation, amendment, cancellation, reference generation, advance notice, and the handling of failed collections, indemnity claims, and mandate migration when a customer changes bank.

A payment scheme is the set of rules, standards, and operating procedures that govern how a particular type of payment works, including who can join, how messages are formatted, how settlement happens, and how disputes are handled. The scheme does not usually move the money itself. It sets the rules that banks and providers follow when they move it. Examples include Visa and Mastercard for cards, the SEPA schemes for euro payments, the UK Faster Payments scheme, and UPI in India. A scheme defines the roles of participants, the timelines for execution, the liability for fraud and errors, the fee structures, and the technical standards for messages and security. It also runs compliance and certification programmes to make sure participants meet the standards. Schemes can be domestic or international, and they can be operated by a central bank, a commercial company, or an industry body. For example, a card scheme licenses banks to issue cards and acquire merchants, while the banks and processors handle the actual transactions. A Business Analyst working on a scheme change, such as a new message version or a new dispute rule, must read the scheme rulebook carefully, because the scheme rules override a single bank internal process and drive system, testing, and customer communication changes.

A payment system operator is the organisation that runs a payment system on a day to day basis. It operates the infrastructure that clears and settles payments, sets the operating hours, manages participant connections, and monitors the system for failures and risk. Examples include the operators of real time gross settlement systems run by central banks, the operators of retail clearing systems such as the UK Pay.UK, and the operators of card clearing systems. The operator is distinct from the scheme, although one organisation may perform both roles. The scheme writes the rules, and the operator runs the system that applies them. The operator is responsible for technical availability, capacity, disaster recovery, participant onboarding, and settlement operations. It also produces the settlement files and reports that banks use for reconciliation. Operators are usually heavily regulated because a failure in a major payment system can stop salaries, supplier payments, and government transfers across a whole economy. For a Business Analyst, the operator matters when defining cut-off times, settlement windows, file formats, and incident procedures. A change in operator hours or a new settlement cycle changes when customer payments arrive, so requirements and customer messages must reflect the operator timetable exactly.

A payment service provider, or PSP, is a company that helps merchants and businesses accept and make payments without building direct connections to every bank and scheme. A PSP offers services such as payment gateway connectivity, card acquiring, alternative payment methods, fraud screening, tokenisation, and settlement reporting, usually through a single integration. Examples include companies that let an online store accept cards, wallets, and bank transfers through one API, and that settle the funds to the merchant bank account. PSPs are normally regulated as payment institutions or electronic money institutions, and they hold client money in safeguarded accounts. They do not usually hold a full banking licence, so they partner with banks for holding funds and for access to clearing systems. The value of a PSP is aggregation and simplification. A small merchant cannot realistically connect to Visa, Mastercard, and several local payment methods separately, but a PSP can offer all of them at once. For a Business Analyst, the PSP is a key integration partner. Requirements must define which payment methods are offered, how settlement and refunds work, how fees are charged, how disputes are passed on, and how the PSP reports transactions so the merchant can reconcile them.

A bank holds a full banking licence, takes deposits from the public, lends money, and holds accounts at the central bank for settlement. A payment service provider, or PSP, holds a narrower licence, usually as a payment institution or electronic money institution, and focuses on moving money and helping merchants accept payments. Banks can create bank money through lending, offer overdrafts, and provide a wide range of services including savings, mortgages, and trade finance. PSPs cannot normally lend customer deposits or create money, and they must safeguard client funds in separate accounts at a bank rather than using them for their own business. Banks connect directly to central bank settlement systems, while PSPs usually reach those systems through a sponsor bank. Banks are supervised under banking regulation with capital and liquidity rules, while PSPs follow payments regulation with safeguarding and conduct rules. In practice the two work together. A PSP may use a sponsor bank for settlement and safeguarding, and a bank may use a PSP for merchant acquiring technology. For a Business Analyst, the distinction matters for onboarding, risk, and product design. A bank account, a PSP merchant account, and an e-money wallet have different protections, different settlement timing, and different rules if the provider fails.

An Electronic Money Institution, or EMI, is a regulated company licensed to issue electronic money, which is a digital store of monetary value that represents a claim on the issuer. When a customer loads funds into an e-money wallet or a prepaid card issued by an EMI, the EMI holds the equivalent amount in a safeguarded account at a bank and issues e-money of the same value to the customer. The customer can then spend that e-money with merchants, send it to other users, or redeem it back into bank money. EMIs do not hold a banking licence, so they cannot lend out customer funds or pay interest on e-money balances in the way a bank pays interest on deposits. Their main duty is safeguarding. Client funds must be kept separate from the EMI own funds, so customers can be repaid if the EMI fails. EMIs are common behind fintech apps, prepaid cards, and cross-border wallets. They offer accounts, cards, and payment services, but the money in an EMI wallet is electronic money, not a bank deposit, and deposit protection schemes usually do not cover it. A Business Analyst working with an EMI must understand safeguarding, redemption rights, and the limits of e-money, because these shape customer terms, disclosures, and the design of top-up, spend, and refund flows.

A payment institution is a regulated company licensed to provide payment services without being a bank or an electronic money institution. Under European regulation, payment institutions can offer services such as executing payment transactions, issuing payment instruments, acquiring card payments, and providing money remittance. Unlike an EMI, a payment institution does not issue electronic money that customers store as a balance. It moves money from a payer to a payee, for example when it processes a merchant card payment or a money transfer, and it does not hold the funds as stored value. Payment institutions must meet capital, safeguarding, and conduct requirements set by their regulator. Client funds that pass through them must be safeguarded, usually in a separate account at a bank, and the firm must have strong governance, risk controls, and complaint handling. Many merchant acquirers, money transfer firms, and payment gateways operate as payment institutions. The licence lets them serve customers across borders in some regimes, for example through passporting in Europe. For a Business Analyst, the licence type matters because it decides what a firm can offer, what disclosures are needed, and how funds must be handled. A feature that stores customer balances needs an EMI licence, while a feature that only moves money may fit a payment institution licence.

An open loop payment uses a system that any licensed participant can join and that works across many merchants and banks. A Visa or Mastercard card is open loop, because the same card works at millions of merchants worldwide and the issuer and acquirer can be different banks. A closed loop payment works only within one system or one merchant group. A store gift card, a campus card, or a transit card that only works on one network is closed loop, because the issuer and the acceptor are the same organisation or a small group of partners. Open loop systems need a scheme, interchange, clearing, and settlement between different parties, which adds cost and complexity but gives wide acceptance. Closed loop systems are simpler and cheaper to run, because the operator controls issuance and acceptance and does not need interbank settlement, but acceptance is limited. Some systems start closed and open up later. A transit card that later works in shops, or a wallet that starts with one merchant and adds more, is moving from closed to open loop. The change brings new regulation, scheme rules, and settlement duties. Analysts must know which model applies, because it decides the parties involved, the fee flows, the dispute process, and whether the product needs a scheme licence or can run on the operator own rules.

In a three-party card scheme, one organisation acts as both the issuer and the acquirer, and the cardholder and the merchant both deal with that same organisation. American Express and Diners Club are classic examples. The scheme sets the rules, issues the card, signs up the merchant, and settles the payment, so there is no interchange fee between separate banks. In a four-party card scheme, the roles are split across four parties, the cardholder, the issuer, the acquirer, and the merchant, plus the scheme itself as the rule maker. Visa and Mastercard are four-party schemes. The issuer gives the card to the cardholder, the acquirer signs up the merchant, and the scheme connects them. The acquirer pays interchange to the issuer for each transaction, and the scheme charges scheme fees to both sides. The four-party model scales better because any licensed bank can issue or acquire, which is why it dominates globally. The three-party model gives the scheme more control over pricing and the customer experience, but growth depends on the scheme signing up both sides itself. For a Business Analyst, the model decides the fee flows, the dispute process, and the parties involved in an investigation. A four-party chargeback passes between acquirer and issuer through the scheme, while a three-party dispute is handled inside one organisation.

A payment gateway is the technology that captures and securely transmits payment details from a customer to the payment processor or acquirer. In online shopping, the gateway is the checkout page or hosted page where the customer enters card details, and the service that encrypts those details and sends them for authorisation. The gateway does not itself move the money or hold the merchant funds. It connects the merchant website or app to the acquirer, the PSP, and the card schemes, and it returns the authorisation result to the merchant so the order can be confirmed or declined. Gateways also offer features such as tokenisation, 3D Secure handling, fraud screening, retry logic, and support for wallets and alternative payment methods. Some gateways are standalone products that a merchant connects to its own acquirer, while others are bundled with acquiring and settlement by a PSP. The distinction matters commercially, because a standalone gateway charges a gateway fee while the acquiring and settlement may come from a different provider. For a Business Analyst, gateway requirements cover checkout design, hosted versus integrated pages, data security and PCI scope, supported payment methods, error handling, and how authorisation, capture, refund, and void messages flow between the merchant, the gateway, and the acquirer.

A payment aggregator is a company that signs up many small merchants under its own merchant account with an acquirer, instead of each merchant holding a separate direct acquiring agreement. The aggregator collects payments on behalf of its merchants, then settles the funds to each merchant after deducting fees. This model lets a small business start accepting card payments quickly with a simple signup and no direct underwriting by a bank. Examples include firms that let a market stall or a small online shop take cards through a single account and a simple pricing plan. The trade-off is control and risk. The aggregator controls the merchant account, so it can hold funds, set reserves, or close the account if risk changes. The merchant does not have a direct relationship with the acquirer and may have less say over settlement timing and dispute handling. Aggregators must underwrite and monitor their merchants for fraud, credit risk, and prohibited business types, because the aggregator bears the risk with the acquirer. Regulation of aggregators varies by country. In India, for example, payment aggregators are licensed by the central bank and must meet capital, governance, and safeguarding rules. Analysts must define onboarding, settlement, payout timing, and dispute flows clearly when working with an aggregator model.

A merchant acquirer is a bank or licensed financial institution that signs up merchants to accept card payments and processes those payments on their behalf. The acquirer provides the merchant account, the card terminal or online acquiring connection, and the settlement of card sales into the merchant bank account. When a customer pays by card, the acquirer receives the authorisation request from the merchant, routes it to the card scheme and the issuer, and later receives the clearing file and settles the funds to the merchant after deducting interchange, scheme fees, and its own markup. The acquirer also bears risk. If a merchant fails to deliver goods and customers raise chargebacks, the acquirer may have to refund the cardholders and then try to recover the money from the merchant. That is why acquirers underwrite merchants, check their business model and financial health, and may hold reserves or require security for higher risk merchants. Acquirers also handle chargeback notifications, representment support, and compliance with scheme rules. Many acquirers now work through PSPs and payment facilitators that handle the merchant relationship and technology, while the acquirer remains the regulated party behind the merchant account. Analysts working on acquiring must define onboarding, pricing, settlement, and dispute flows precisely.

A payment facilitator, or PayFac, is a company that lets other businesses accept card payments by signing them up as sub-merchants under the PayFac own master merchant account with an acquirer. The PayFac handles onboarding, underwriting, pricing, settlement, and support for its sub-merchants, while the acquirer provides the underlying acquiring licence and settlement rails. The model is common in software platforms. A booking platform, a marketplace, or a practice management system can embed payments for its users without each user signing a separate acquiring contract. The PayFac can onboard a sub-merchant in minutes with a simple online flow, fund them quickly, and split payments between the platform and the sub-merchant. The PayFac also takes on risk. It must underwrite sub-merchants, monitor transactions for fraud and unusual activity, manage chargebacks, and hold reserves where needed. If a sub-merchant fails or commits fraud, the PayFac is liable to the acquirer. Regulation and scheme registration apply. Visa and Mastercard require PayFacs to register and follow specific rules on sub-merchant disclosure and monitoring. For a Business Analyst, PayFac requirements cover sub-merchant onboarding, know your customer checks, funding and split logic, fee structures, and chargeback handling across many small merchants under one master account.

Embedded finance is the integration of financial services, such as payments, lending, insurance, or accounts, directly inside a non-financial product or platform, so the customer uses the service without leaving that product. Examples include a ride hailing app that pays the driver instantly, an e-commerce site that offers checkout finance, a marketplace that gives sellers a business account and a card, and a software platform that lets its users send invoices and collect payments. The customer sees a smooth experience, while a licensed bank or fintech provides the regulated service behind the scenes through APIs. The platform focuses on its core product, and the financial provider handles licensing, compliance, and money movement. Embedded finance is growing because APIs and Banking as a Service make it possible to add financial features without building a bank. The benefits are convenience, higher conversion, and new revenue for the platform. The risks include unclear responsibility when something goes wrong, data sharing concerns, and the need for strong customer protection. For a Business Analyst, embedded finance requirements must define who the customer contracts with, who holds the funds, how complaints are handled, and how the user journey moves between the platform and the financial provider without confusing the customer.

Banking as a Service, or BaaS, is a model where a licensed bank provides its banking infrastructure, such as accounts, cards, payments, and compliance, to other companies through APIs, so those companies can offer banking products under their own brand without holding a banking licence. A fintech, a retailer, or a software platform can use BaaS to open accounts for its customers, issue cards, process payments, and manage balances, while the partner bank holds the deposits, runs the core ledger, and meets regulatory duties. The BaaS provider may be the bank itself or a middleware firm that connects many banks to many brands through one integration layer. The model lets brands launch financial products quickly and lets banks earn revenue from their licence and infrastructure. The risks are shared and must be defined clearly. The bank remains responsible for regulatory compliance, safeguarding, and reporting, while the brand is responsible for the customer experience and first line support. If the brand mis-sells a product or the bank systems fail, customers can be harmed and both parties face regulatory attention. For a Business Analyst, BaaS requirements cover account opening, know your customer checks, card issuance, payment limits, reconciliation, and the division of duties between the bank, the middleware provider, and the brand.

A nostro account and a vostro account are two views of the same correspondent banking account. Nostro means our account with you, and vostro means your account with us. When Bank A in London holds an account in US dollars with Bank B in New York, Bank A calls it a nostro account, because it is Bank A money held at Bank B. Bank B calls the same account a vostro account, because it is Bank A money held on Bank B books. Banks hold nostro accounts in foreign currencies so they can make and receive payments in those currencies without using a central bank system in that currency. For example, a UK bank that pays suppliers in dollars holds a dollar nostro account with a US correspondent bank, and it instructs that bank to pay from the account. Nostro accounts need careful liquidity management, because the bank must keep enough balance to meet outgoing payments, and idle balances earn little return. They also need daily reconciliation, because differences between the bank own record and the correspondent statement can hide errors or fraud. Vostro accounts are a service a bank offers to other banks, and the bank must manage the risk, the fees, and the compliance screening for the account holder. Analysts working on cross-border payments must understand nostro and vostro accounts, because funding, cut-off times, and settlement all depend on them.

SWIFT is the Society for Worldwide Interbank Financial Telecommunication. It is a global messaging network used by banks and financial institutions to send secure instructions and information to each other. When a bank in India needs to tell a bank in the United Kingdom to pay a beneficiary, it often sends that instruction over SWIFT. More than 11,000 institutions in over 200 countries are connected, and they exchange millions of messages every day, covering customer payments, bank to bank transfers, trade finance, securities, and treasury operations.

The most important fact about SWIFT, and the one beginners most often get wrong, is that SWIFT is a messaging system, not a payment system. It carries instructions, not money. It holds no accounts and it settles nothing. When a bank sends an MT103 payment instruction over SWIFT, the actual value moves separately, through correspondent accounts that banks hold with each other, or through a settlement system. SWIFT also provides a common language for those instructions, standard message types such as MT103, MT202, and MT940, so that a bank in any country can read a message sent by a bank in any other country.

SWIFT also provides services beyond messaging. It assigns BIC codes that identify institutions, it provides the gpi tracker that lets banks and customers follow a cross border payment, and it supports the migration to ISO 20022 messages. It sets security standards that members must follow, and it helps members screen messages and investigate failures. For a learner, the practical lesson is to treat SWIFT as the postal service of international banking: it delivers the letter reliably and securely, but it does not move the money inside the envelope. The money moves through banking accounts and settlement systems.

No, SWIFT is not a payment system. It is a messaging system. This distinction is the single most important idea in cross border payments, and confusing the two leads to wrong designs, wrong test cases, and wrong explanations to stakeholders.

A payment system moves value and settles obligations. It holds settlement accounts, usually at a central bank, and when a payment settles there, the transfer of value is final. Examples are TARGET2, Fedwire, CHAPS, and RTGS systems. They manage liquidity, finality, and settlement risk. If a participant fails before settlement, the payment system has rules for what happens to the unsettled payments.

SWIFT does none of that. It holds no settlement accounts and moves no money. It provides a secure network, a common message format, and a directory of institutions, so banks can send each other instructions. A bank sends an MT103 over SWIFT to instruct another bank to pay a beneficiary, and the value moves through a correspondent account: the sending bank debits the account it holds with the receiving bank, or instructs a third bank to do so. SWIFT also carries balance reports, status updates, and investigation messages, but in every case the message is separate from the money movement. A useful analogy is email versus a bank transfer. Email carries the instruction to pay, but the transfer happens in the banking system. SWIFT is the secure email of international banking, with standard formats, authentication, and tracking, but it is not the transfer itself.

A BIC is a Business Identifier Code, also known as a SWIFT code. It is a unique code that identifies a financial institution, and sometimes a specific branch, in international payments. It is defined by the ISO 9362 standard and is usually 8 or 11 characters long. The first four characters identify the bank, the next two identify the country, the next two identify the location, and the optional final three identify the branch. For example, in a typical BIC, you can read the bank, the country, and the city from the code itself.

BICs are used in payment messages to tell every party exactly which institution is involved. In an MT103, the BIC appears in fields such as :57A: for the account with institution and :59: for the beneficiary bank, so the message can be routed correctly even when bank names are similar or spelled differently. In ISO 20022 messages, the BIC appears in the agent elements for debtor agent, creditor agent, and intermediary agents. Without a correct BIC, a payment can be delayed, routed to the wrong branch, or rejected.

A BIC identifies an institution, not an account. The account number is a separate piece of data, and the two must be used together. A related identifier, the IBAN, identifies a specific account in many countries. A business analyst must know how to validate a BIC: check its length, check that the country code matches the expected country, confirm that the institution exists in the SWIFT directory, and confirm whether the 11 character branch code is needed or the 8 character head office code is enough. A wrong BIC is one of the most common causes of failed cross border payments, and it is entirely preventable with a simple directory check at the point of entry.

An MT103 is the SWIFT message type used for a single customer credit transfer. It is the most common message in cross border payments, and the one every payments analyst must be able to read. When a customer asks their bank to send money to a beneficiary in another country, the debtor bank creates an MT103 and sends it to the next bank in the chain, usually the creditor agent or an intermediary. The message instructs the receiving bank to pay the beneficiary and carries all the information the receiving bank needs to execute the payment and reconcile it. Since coexistence ended on 22 November 2025, a new cross-border payment travels as a pacs.008 instead of an MT103.

The MT103 is a customer payment, not a bank to bank payment. That is why it carries customer details such as the ordering customer and the beneficiary, remittance information explaining why the payment was made, and charge details showing who pays the fees. The bank to bank movement of funds that settles the MT103 is handled separately, often through a cover payment such as an MT202 COV, or through a direct debit of a correspondent account. The MT103 tells the receiving bank what to do for the customer, while the cover tells the banks how to settle between themselves.

Understanding the MT103 matters because it is the message that customers see reflected in their accounts, and it is the message that operations teams investigate when something goes wrong. If a beneficiary complains that money has not arrived, or that the amount is short, or that the reference is missing, the first document an analyst asks for is the MT103. Its fields show the value date, the amount, the ordering customer, the beneficiary, the charges, and the remittance information. If you can read an MT103 field by field, you can trace almost any customer payment problem to its cause.

Each field in an MT103 has a specific purpose, and reading them in order tells the story of the payment. Field :20: is the transaction reference number, a unique 16 character reference assigned by the sender. It is the key that links the MT103 to the sender internal system, to investigations, and to the gpi tracker. If two payments share a reference, reconciliation and tracking break down, so the reference must be unique per payment.

Field :32A: carries the value date, the currency, and the amount. The value date is the date on which the funds are to be available to the beneficiary, and it drives interest calculations and cut off decisions. The currency and amount must match the customer instruction exactly. Field :50K: identifies the ordering customer, with name and account details, so the receiving bank knows who sent the money and can apply sanctions screening. Field :57A: names the account with institution, which is the bank that holds the beneficiary account or the next bank in the chain, identified by its BIC. Field :59: identifies the beneficiary customer, with name and account number, and it must be accurate enough for the creditor agent to credit the right account.

Field :70: carries remittance information, a free text explanation of what the payment is for, such as an invoice number. This field is what lets the beneficiary reconcile the receipt against their own records. Field :71A: states the charge arrangement, whether charges are borne by the ordering customer, the beneficiary, or shared. Other fields add detail: :52A: names the ordering institution, :53B: names the sender correspondent, :54A: names the receiver correspondent, and :72: carries sender to receiver information. Together these fields form a complete instruction, and a single wrong field can delay, misroute, or block the payment.

The difference between an MT103 and an MT202 is the difference between a customer payment and a bank to bank payment. An MT103 is a single customer credit transfer. It carries the ordering customer, the beneficiary, remittance information, and charge details, because a real customer is paying another real customer. An MT202 is a general financial institution transfer. It moves money between banks for their own account, for example when a bank transfers its own funds, settles a position, or covers a customer payment. It carries no beneficiary customer details, because there is no underlying customer payment to describe.

This difference matters in how the two messages are used together. In a cover payment, an MT103 is sent directly to the creditor agent with the full customer details, while an MT202 COV is sent through the correspondent chain to move the funds that settle the MT103. The MT103 and the MT202 COV are linked by the same transaction reference and the same UETR, so the receiving bank can match the cover funds to the customer instruction. Without the link, the creditor agent would receive money with no idea which customer it belongs to, and the customer instruction would arrive with no funds behind it.

From a compliance point of view, the difference also matters. Because an MT103 names the ordering customer and the beneficiary, it can be screened against sanctions lists and its remittance information can be reviewed. An MT202 without cover information does not carry those details, which is why the MT202 COV variant was introduced. A business analyst must never use an MT202 where an MT103 is needed, and must never put customer details into a plain MT202. Choosing the wrong message type is a design error that creates reconciliation failures and compliance risk.

A cover payment is a method for settling a cross border customer payment in which the customer instruction and the funds travel separately. The MT103, with full customer details, is sent directly from the debtor agent to the creditor agent. The funds are sent separately through the correspondent banking chain, usually as an MT202 COV, from the debtor agent through one or more intermediary banks to the creditor agent. The two legs are linked by the same reference and the same UETR, so the creditor agent can match the incoming funds to the customer instruction.

The reason for splitting the payment this way is speed and transparency. In a serial payment, the MT103 travels step by step through every intermediary, and each bank takes time to process it, apply screening, and deduct charges. In a cover payment, the creditor agent receives the full customer details immediately and directly, so it can screen the payment, identify the beneficiary, and prepare to credit the account without waiting for the funds to travel through the chain. The funds still travel through intermediaries, but the information does not have to wait for them.

Cover payments also improve transparency for compliance. Because the MT103 goes directly to the creditor agent, the creditor agent sees the ordering customer, the beneficiary, and the remittance information in full, even if an intermediary in the funds chain would otherwise have obscured them. The MT202 COV carries a copy of key customer details for the same reason. For a business analyst, the practical lesson is to check which method a payment uses. If a beneficiary complains about delay, the question is whether the MT103 arrived but the cover funds are still in transit, or whether the funds arrived but the MT103 is missing. Each case has a different investigation path.

A serial payment is a method for settling a cross border customer payment in which the instruction and the funds travel together, step by step, through every bank in the chain. The debtor agent sends the MT103 to the first intermediary, which processes it, deducts any charges, and forwards it to the next bank, and so on until the MT103 reaches the creditor agent. At each step, the bank debits the account of the previous bank and credits the account of the next bank, so the funds move along the same path as the message. There is only one chain, and every bank in that chain sees the same MT103.

Serial payments are simple to understand and easy to trace in one sense, because there is a single sequence of messages to follow. But they are slower and less transparent than cover payments. Each intermediary must process the message before forwarding it, which adds time, and each intermediary may deduct charges, so the final amount credited can be less than the original amount. Each bank also applies its own screening, and if any bank in the chain holds the payment for review, the whole payment waits. There is no shortcut for the creditor agent to see the customer details early, because the MT103 only arrives after it has passed through every intermediary.

If a payment is serial, the investigation follows the chain link by link, asking each bank when it received the MT103, what charges it deducted, and when it forwarded the payment. If a payment is a cover payment, the investigation splits into two tracks, the MT103 track and the cover funds track, and each must be checked separately.

An MT202 COV is the cover variant of the MT202 financial institution transfer, and it exists to solve a transparency problem. A plain MT202 moves money between banks for their own account, and it carries no customer details. If a plain MT202 were used to settle a customer payment, the intermediary banks and the creditor agent would see money moving with no idea who the underlying ordering customer or beneficiary was. That gap created a compliance and reconciliation risk, because banks could not screen the underlying parties or match the funds to the right customer instruction.

The MT202 COV fixes this by carrying the cover details. It is sent through the correspondent chain to move the funds that settle an MT103 customer payment, and it includes the key customer information from the MT103, such as the ordering customer and the beneficiary, in its fields. The MT103 itself is sent directly to the creditor agent with the full details, and the MT202 COV is linked to it by the same transaction reference and the same UETR, so the creditor agent can match the incoming funds to the customer instruction when both legs arrive.

For a business analyst, the MT202 COV is a good example of how message design responds to regulation. The plain MT202 was technically sufficient to move the money, but it was not sufficient for transparency. The COV variant adds the information that compliance, operations, and reconciliation teams need, without changing the underlying settlement mechanism. When you investigate a cover payment, always ask for both messages. The MT103 shows what the customer asked for, the MT202 COV shows how the funds travelled, and the shared reference and UETR prove that the two legs belong to the same payment.

MT900 and MT910 are confirmation messages, and they answer a simple question: did the money actually move? An MT900 is a confirmation of debit. It is sent by an account servicing bank to an account owner to confirm that an amount has been debited from the owner account. An MT910 is the mirror image, a confirmation of credit, sent to confirm that an amount has been credited to the owner account. Both messages are used in correspondent banking, where one bank holds an account with another bank and needs formal confirmation that a debit or credit has been applied.

These messages matter because a payment instruction is not the same as a payment completion. An MT103 instructs a bank to pay, but it does not prove that the bank has done so. An MT202 instructs a bank to move funds, but it does not prove that the correspondent account was debited. The MT900 and MT910 close that gap. When a bank sends funds through a correspondent, it waits for the MT900 to confirm the debit from its own account. When a bank receives funds, the MT910 confirms the credit to its account.

For a business analyst, MT900 and MT910 appear in reconciliation and investigation work. If a customer says a payment was sent but the beneficiary has not received it, the analyst checks whether the sending bank received an MT900, whether the intermediary received an MT910, and where the chain of confirmations stops. A missing MT900 may mean the debit was never applied. A missing MT910 may mean the credit was applied to the wrong account or is held for review. These messages are short and simple, but they are the proof that the money moved, and without them a payment cannot be treated as settled.

MT940 and MT942 are account statement messages, and they are the backbone of bank reconciliation. An MT940 is a customer statement message. It is sent by an account servicing bank to an account owner, usually at the end of the business day, and it lists the opening balance, every debit and credit posted to the account during the period, and the closing balance. It is the formal record that lets a bank or a corporate customer check that its own books match the bank books. An MT942 is an interim transaction report, sent during the day, with the transactions posted since the last statement, so the account owner can see intraday movements without waiting for the end of day statement.

These messages matter because every payment eventually appears as a line on a statement. A corporate treasury team uses the MT940 to reconcile its receipts and payments, to confirm that a supplier was paid, and to spot unexpected debits. A bank uses the MT940 to reconcile its correspondent accounts, to confirm that cover funds arrived, and to detect breaks where its own records and the servicing bank records disagree.

For a business analyst, the MT940 is where many payment problems become visible. A missing credit, a wrong amount, an unexpected charge, or a duplicate debit will all show up on the statement, and the analyst must trace each line back to the original payment message. The statement carries its own reference numbers that link each entry to the underlying MT103, MT202, or other instruction. If you can read an MT940, you can reconcile a correspondent account, investigate a break, and prove to a customer or an auditor exactly what happened to their money.

SWIFT gpi is the Global Payments Innovation initiative, a service that makes cross border payments faster, more transparent, and more traceable. Before gpi, a cross border payment could take several days, the customer had no idea where the money was, and the final amount was uncertain because each intermediary could deduct charges without warning. Gpi was built to fix those three problems by setting service level rules for member banks, requiring same day processing, end to end tracking, and transparency on fees and foreign exchange.

The core of gpi is the tracker. Every gpi payment carries a Unique End to End Transaction Reference, known as the UETR, which stays with the payment from the debtor agent to the creditor agent. Each bank in the chain confirms when it received the payment, what charges it deducted, and when it forwarded the payment, and those confirmations feed the tracker. The debtor bank, and often the customer, can see the payment status in real time: whether it is with the debtor agent, an intermediary, or the creditor agent, whether it has been credited, and what fees were taken at each step. That visibility changes the customer experience from waiting in the dark to watching the payment move.

Member banks commit to processing gpi payments on the same day, to passing on remittance information unaltered, and to disclosing charges and exchange rates. For a business analyst, the practical question is always whether a given payment is gpi enabled, whether it carries a UETR, and whether each bank in the chain is a gpi member. If the answer is yes, tracking and investigation become much faster. If the answer is no, the investigation falls back to manual messages and phone calls.

A UETR is a Unique End to End Transaction Reference, a 36 character identifier in the standard UUID format that stays with a payment from start to finish. It is assigned by the debtor agent when the payment is created, and every bank in the chain carries the same UETR forward, whether the payment travels as an MT103, an MT202 COV, or an ISO 20022 pacs.008 message. It is the one identifier that links every leg of the payment, every confirmation, and every investigation message to the same underlying transaction.

The UETR is what makes SWIFT gpi tracking possible. Each bank in the chain sends a status confirmation to the gpi tracker when it receives the payment, when it forwards it, and when it credits the beneficiary. The tracker collects those confirmations under the UETR and builds a live picture of where the payment is, how long it has spent at each bank, and what charges were deducted.

To track a payment, you need the UETR from the debtor bank, usually shown on the payment confirmation or available from the bank operations team. The customer cannot track a payment with only an amount and a date. The UETR is the key. A business analyst should always ask for the UETR at the start of any cross border investigation, record it in the case notes, and use it to link the MT103, the cover message, the gpi confirmations, and any investigation messages. Without the UETR, an investigation is slow and uncertain. With it, the payment can be found in minutes.

To track a SWIFT payment, start by getting the UETR from the bank that sent the payment. The UETR is the Unique End to End Transaction Reference, a 36 character identifier that stays with the payment through every bank in the chain. It is usually printed on the payment confirmation or available from the sending bank operations team. Without the UETR, tracking is slow, because each bank uses its own reference and there is no single key to link the legs together.

If the payment is gpi enabled, the sending bank can query the gpi tracker by UETR and see the live status. The tracker shows each bank that has handled the payment, when it received the instruction, what charges it deducted, when it forwarded the payment, and whether the beneficiary has been credited. If the payment is not gpi enabled, there is no tracker, and tracking becomes manual.

For a non gpi payment, the sending bank must send an investigation message, such as an MT199, to the next bank in the chain, asking for the status and the onward reference, and that bank must ask the next, and so on. This can take days. A business analyst who is investigating a payment should record the UETR, check the gpi tracker first, and only then start manual investigations. Always ask the customer for the payment confirmation, the value date, and the exact beneficiary details, because a wrong account number or a wrong BIC is a common cause of delay, and the tracker will show the payment held at the creditor agent for repair.

When a SWIFT payment fails, the first step is to find out where it failed and why, and that depends on the type of failure. The most common failures are a wrong beneficiary account number, a wrong BIC, insufficient funds, a sanctions screening hit, missing information, or a bank in the chain rejecting the message for a format error.

If the payment was rejected by a bank in the chain, that bank returns the funds and sends a return message, usually an MT103 return or an MT199 explaining the reason. The debtor agent receives the return, credits the debtor account, and informs the customer of the reason, for example that the beneficiary account does not exist or that a mandatory field was missing. If the payment was held for compliance review, it may sit with a bank while sanctions screening is completed, and it will either be released, returned, or blocked depending on the outcome. If the payment was credited to the wrong account, a recall must be requested, and the creditor agent must ask the wrong beneficiary for consent to return the funds, which can take time.

The customer experience depends on how well the bank communicates. A good bank tells the customer the payment has failed, gives the reason in plain language, states whether the funds have been returned, and explains what needs to be corrected before the payment can be sent again. A business analyst who handles these cases should record the UETR, collect the MT103 and any return messages, confirm whether the funds have been returned, and check whether charges were deducted and need to be refunded. Never resend a failed payment without fixing the root cause, because the same error will fail again and each attempt costs time, charges, and customer trust.

ISO 20022 is the global standard for exchanging electronic messages between financial institutions. It defines a common language that banks, payment systems, market infrastructures and corporates use to describe payments, securities, trade and card transactions. Instead of each system inventing its own format, ISO 20022 provides a shared dictionary of business concepts, such as debtor, creditor, amount and value date, plus a set of message definitions built on top of that dictionary.

The standard is maintained by ISO Technical Committee 68 and is syntax independent in principle, but in practice almost all ISO 20022 messages today are expressed in XML. Each message type has a name, such as pacs.008 or pain.001, and a published schema that spells out exactly which elements are mandatory, which are optional and what values are allowed. Because the data is structured and labelled, a receiving system can parse a message without guessing what a free text field means.

ISO 20022 matters because it is replacing the older MT message formats on SWIFT and in many domestic systems. It carries richer data, for example full structured addresses, longer remittance information and explicit purpose codes, which helps with straight through processing, sanctions screening, reconciliation and regulatory reporting. Learning ISO 20022 is therefore essential for anyone working in payments operations, correspondent banking or payment product design.

MT messages were designed in the 1970s for a world of telex style messaging, and their design shows it. An MT message is a fixed sequence of numbered fields, such as :32A: for value date and amount or :70: for remittance information, and much of the content lives in free text. Free text is flexible for humans but hard for machines. A bank receiving an MT103 has to parse unstructured lines to work out who the debtor is, what the payment is for and whether it needs screening, and different banks write the same information in different ways.

ISO 20022 fixes this by making the data structured and self describing. Every piece of information has its own named XML element, so a system can read the debtor name, the structured address, the charge bearer and the remittance information without text parsing. Structured data also means more data can travel with the payment: longer remittance references, invoice details, purpose codes and full party identification. That richer data improves straight through processing rates, reduces manual repair, and gives compliance teams cleaner inputs for sanctions and anti money laundering screening.

The migration is also driven by harmonisation. When every market uses the same standard, a cross border payment does not need to be translated between formats at each hop, which removes a whole class of truncation and data loss errors. Regulators support the change too, because richer, structured payment data improves transparency and reporting. The cost is real, since every bank must rebuild interfaces and mappings, but the industry has accepted that the old format cannot carry the data modern payments need.

pacs.008 is the ISO 20022 customer credit transfer message, formally called FIToFICustomerCreditTransfer. It is the message a bank sends to another bank to move money on behalf of a customer. It is the direct successor to the MT103, and it is the workhorse of cross border payments: when you send money from your account in one country to a beneficiary in another, a pacs.008 is very likely carrying that instruction between the banks involved.

The message has a group header with a message identification and creation time, then one or more credit transfer transaction information blocks. Each block carries the instructed amount and currency, the debtor (the payer) and debtor agent, the creditor (the beneficiary) and creditor agent, the value date, the charge bearer, and remittance information. It can also carry purpose codes, structured addresses, intermediary agents, and regulatory reporting details. Unlike the MT103, where much of this lived in free text, every element in pacs.008 is a labelled field with a defined format.

In a typical correspondent banking chain, the debtor bank creates a pacs.008 and sends it to the next bank in the chain, which either settles it or forwards a new pacs.008 onward. Each hop can add its own processing, but the core payment details travel intact. Because the message is so central, most ISO 20022 migration work starts with pacs.008: getting it right is the difference between a payment that settles cleanly and one that lands in a repair queue.

pacs.002 is the ISO 20022 payment status report, formally called FIToFIPaymentStatusReport. It is the message a bank sends to tell the previous bank in a payment chain what happened to a payment. Its job is to report status: accepted, rejected, pending, or settled, along with a reason code when something went wrong. It replaces the MT199 free format message and parts of the MT102 and MT900/910 acknowledgement flow, but with structured status codes instead of free text.

The message references the original instruction through its message identification and transaction identification, so the receiving bank can match the status to the payment it sent. It then carries a transaction status, such as ACCP for accepted, RJCT for rejected, or ACSP for accepted and settlement in progress, plus a status reason if needed. For a rejection, the reason code explains why: for example, the account is closed, the format is invalid, or the payment failed a compliance check. That structured reason is what lets the sending bank act automatically, such as returning funds to the customer or asking for corrected details.

pacs.002 is essential to the modern payment experience because it closes the feedback loop. Without it, a sending bank would not know whether its pacs.008 was accepted until the money moved or a customer complained. With pacs.002, exceptions are visible within minutes, and banks can build tracking services that show customers exactly where their payment stands. When you see a payment marked as rejected with a specific code, a pacs.002 is usually the message that delivered that news.

pain.001 is the ISO 20022 customer credit transfer initiation message, formally called CustomerCreditTransferInitiation. It is the message a corporate customer sends to its bank to instruct a payment. The pain family covers the customer to bank space, while the pacs family covers bank to bank. So pain.001 is the starting point: a company payroll file, a supplier payment batch, or a single payment instruction from a treasury system all typically begin life as a pain.001.

The message has a group header with the number of transactions, the total amount and the initiating party, followed by one or more payment information blocks. Each block can contain many individual credit transfer transactions, which is how a single file can carry thousands of salary payments. Each transaction carries the debtor account, the creditor name and account, the amount, the requested execution date, remittance information and, where needed, the creditor agent details. The bank validates the file, checks balances and limits, and then converts the accepted instructions into pacs.008 messages for the interbank leg.

For corporates, pain.001 is attractive because it is a single standard format that works with many banks, replacing the proprietary file formats each bank used to demand. For banks, it is attractive because the structured data can be validated automatically before anything is sent. If you work in corporate payments, treasury or ERP integration, pain.001 is the message you will meet first and most often.

camt.053 is the ISO 20022 bank to customer statement message, formally called BankToCustomerStatement. It is the electronic bank statement: the message a bank sends to its customer, usually a corporate, listing all the entries posted to an account over a period, typically a day. It replaces the MT940 statement message and is the backbone of corporate cash management and automated reconciliation.

Each camt.053 carries a statement identification, the account it relates to, the opening and closing balances, and a list of entries. Every entry shows the amount, the credit or debit mark, the value date and booking date, and a reference to the underlying transaction. Crucially, entries can carry rich transaction details, including the counterparty name, the remittance information from the original payment, and the end to end identification. That detail is what lets a corporate treasury system match a bank statement line to an invoice or a payment instruction automatically, without a human reading a statement.

The difference from a paper statement is not just the format but the purpose. camt.053 is designed to be consumed by software, not read by people. A corporate that receives camt.053 files daily can reconcile its accounts every morning, spot missing or unexpected entries, and update its cash position in near real time. For banks, producing accurate camt.053 files is a key part of the ISO 20022 migration, and for corporates it is often the first visible benefit of the new standard.

Mapping an MT103 to a pacs.008 is the core exercise of the ISO 20022 migration, and most of the mapping is straightforward once you know the field pairs. The value date, currency and amount in field :32A: become the Interbank Settlement Date and the Instructed Amount in pacs.008. The ordering customer in :50K: maps to the Debtor, with the name and address lines carried into the Debtor Postal Address. The beneficiary in :59: maps to the Creditor, again with name and address. Remittance information in :70: maps to Remittance Information, which in ISO 20022 can be structured or unstructured. The charges instruction in :71A:, OUR, SHA or BEN, maps to the Charge Bearer element.

Some fields need more care. Field :52A:, the ordering institution, maps to the Debtor Agent, and :57A:, the account with institution, maps to the Creditor Agent. Field :53B:, the sender correspondent, maps to the Instructed Agent, and :56A:, the intermediary, maps to the Intermediary Agent. The sender reference :20: becomes the Instruction Identification, and the related reference :21: is carried in the matching reference element. Field :72:, sender to receiver information, has no single equivalent and must be split: structured parts go to their matching elements, and anything left over goes to the instruction for the next agent.

The hard part is the fields that do not match. ISO 20022 expects structured addresses, so a :50K: block of free text must be parsed into street, town and country. Data truncated in MT by field length limits can now be carried in full, but banks must decide how to handle legacy free text that does not fit the new structure. A good mapping tests clean and messy cases alike, and documents every decision so the same MT103 always produces the same pacs.008.

CBPR+ stands for Cross Border Payments and Reporting Plus. It is the working group that defines how ISO 20022 is used for cross border payments on the SWIFT network. ISO 20022 itself is a broad standard with many optional elements, and different banks could implement it in different ways. CBPR+ exists to prevent that fragmentation: it publishes usage guidelines that say exactly which elements are mandatory, which are optional, and which rules apply for cross border payments, so that a pacs.008 sent by a bank in Singapore is understood the same way by a bank in Germany.

The group is made up of banks, market infrastructures and SWIFT, and its guidelines are the practical rulebook for the migration. They cover message versions, character sets, address formats, charge bearer rules, and how the coexistence period was handled, when MT and ISO 20022 messages both flowed. CBPR+ also defined the translation rules used during coexistence, so that a payment starting as an MT103 could be converted to pacs.008 without losing information, and vice versa.

For anyone implementing ISO 20022, CBPR+ is the document that matters most after the standard itself. Reading the raw ISO 20022 schema tells you what is possible; reading the CBPR+ usage guidelines tells you what you must actually do. The guidelines are updated regularly, so implementation teams track new releases and plan their changes around them. If a payment fails between two banks, one of the first questions is usually whether both sides followed the same CBPR+ version.

The ISO 20022 migration has been a multi year programme, and its exact dates differ by market and by system, so the timeline is best understood as a sequence of milestones rather than a single deadline. SWIFT began the cross border migration in November 2022, when banks became able to send and receive ISO 20022 messages on the SWIFT network alongside MT messages. That started a coexistence period in which both formats flow, with translation services converting between them where needed.

The coexistence period ended on 22 November 2025, when MT messages for cross border payments and reporting were retired. The migration is complete: all cross border payment instructions on the SWIFT network now use ISO 20022. During coexistence, banks had to be able to receive ISO 20022 even if they still sent MT, and they had to handle the data differences between the two formats. After the coexistence period ended, MT messages in the affected categories are no longer supported on the SWIFT network.

Domestic systems have their own timelines. The Eurosystem, the US Federal Reserve, the Bank of England and other market infrastructures each ran their own ISO 20022 migrations, some finishing earlier and some later than the SWIFT cross border date. The practical lesson for learners is to check the timeline for the specific market and message set you work in, and to treat any date you read as a versioned fact: confirm it against the current SWIFT or central bank publication before relying on it in a project plan.

A structured address in ISO 20022 is an address broken into labelled components instead of written as free text lines. Rather than four lines of unstructured text, a structured address has separate elements for street name, building number, postcode, town name, country subdivision and country code. For example, instead of a single block reading 33 Punya Building, 5th Cross, Bangalore 560035, India, the structured version carries the street as 5th Cross, the building as Punya Building, the town as Bangalore, the postcode as 560035 and the country as IN, each in its own field.

The reason this matters is screening and straight through processing. Sanctions screening engines, anti money laundering systems and payment repair teams all need to find the country, city and street reliably. In free text, the country might be written as India, IND, or buried in the middle of a line, and different banks write the same address differently. With a structured address, the country is always in the country element as a two letter ISO code, the town is always in the town element, and a machine can read it without guessing. That reduces false positives in screening and cuts the number of payments that stop for manual repair.

The migration challenge is that most legacy data is unstructured. Banks hold customer addresses as free text, and converting them to structured form means parsing millions of records, some of which are incomplete or ambiguous. CBPR+ therefore allows a hybrid approach during the transition, where an address can carry both structured elements and unstructured lines, but the direction of travel is clear: structured is the target, and counterparties increasingly expect it. If you are building a payment system, design for structured addresses from the start.

pain and pacs are two families of ISO 20022 messages, and the difference is who is talking to whom. pain stands for Payment Initiation, and it covers the customer to bank space: a corporate, or an individual through a banking channel, instructing its bank to make a payment. pacs stands for Payments Clearing and Settlement, and it covers the bank to bank space: one financial institution instructing another to move money. The same payment therefore typically starts as a pain message and continues as a pacs message.

Take a company paying a supplier. The company treasury system sends a pain.001 to its bank with the payment instruction. The bank validates it, debits the company account, and then sends a pacs.008 to the supplier bank through the payment chain. When the supplier bank receives the funds, it may send a pacs.002 status report back, and the company bank sends the company a camt.053 statement and possibly a pain.002 status report confirming the outcome. The pain message is the instruction into the banking system; the pacs message is the movement of money between banks.

The practical consequence is that the two families carry different data. pain messages carry customer facing detail such as the debtor account, the requested execution date and the ultimate debtor. pacs messages carry interbank detail such as settlement dates, intermediary agents and charge bearer rules. People new to ISO 20022 often confuse them because both describe a credit transfer, but the rule is simple: if the sender is a customer and the receiver is a bank, it is pain; if both sides are banks, it is pacs.

camt.052, camt.053 and camt.054 are three related ISO 20022 cash management messages, and the difference is timing and granularity. camt.052 is the Bank to Customer Account Report: an intraday report showing account activity so far during the day, sent at intervals while the day is still in progress. camt.053 is the Bank to Customer Statement: the end of day statement showing all entries for a full period, usually a day, with opening and closing balances. camt.054 is the Bank to Customer Debit Credit Notification: a message about a single entry, sent when that entry posts rather than waiting for a statement.

A corporate treasury team uses all three for different purposes. camt.052 tells them their intraday cash position, so they can see what has arrived by mid morning and plan funding for the rest of the day. camt.053 is the formal record used for reconciliation: the treasury system matches each statement line against its own ledger and flags anything unmatched. camt.054 is the real time alert: when a large credit lands, the notification arrives immediately, so the treasury system can act on it without waiting for the next statement.

All three share the same building blocks, account identification, balances and entry details, but they differ in scope. camt.052 and camt.053 can carry many entries and balances; camt.054 carries one notification, often with richer detail about that single entry. In MT terms, camt.052 roughly replaces the MT942 intraday report, camt.053 replaces the MT940 statement, and camt.054 replaces the MT900 and MT910 debit and credit confirmations. If you only remember one distinction, remember this: 052 is intraday, 053 is end of day, 054 is per entry.

pacs.004 is the ISO 20022 payment return message, formally called PaymentReturn. It is the message a bank sends to return a payment that has already been received but cannot be applied, or must be sent back. Common reasons include the beneficiary account being closed, the account number being wrong, the beneficiary being deceased, or the receiving bank being unable to credit the funds. It replaces the MT103 return flow and the MT202 return in the interbank space.

The message is designed to be traceable back to the original payment. It carries a reference to the original instruction, the original transaction identification, the amount being returned, and a return reason code explaining why. That linkage matters, because the bank that receives a pacs.004 needs to know exactly which payment is coming back so it can credit the right customer and close the right case. The return reason code also matters: it tells the originating bank whether the problem is fixable, such as a wrong account number the customer can correct, or final, such as a closed account.

A return is different from a rejection. A rejection, reported by pacs.002, happens before the money moves: the receiving bank refuses the payment and it never settles. A return happens after the money has moved: the funds arrived, could not be applied, and are now being sent back. Returns take time, because the money has to travel back along the chain, and each hop may deduct charges depending on the charge bearer. For operations teams, pacs.004 is the message that turns a stuck payment into a resolved one, and the return reason code is the key to explaining to the customer what happened.

pacs.009 is the ISO 20022 financial institution credit transfer message, formally called FinancialInstitutionCreditTransfer. It is the bank to bank equivalent of pacs.008: while pacs.008 moves money on behalf of a customer, pacs.009 moves money between financial institutions for their own account. Typical uses include a bank settling its own obligations, moving liquidity between its own accounts, funding a nostro account, or settling a foreign exchange deal. It replaces the MT202 and MT202 COV messages.

The message structure is similar to pacs.008, with a group header and credit transfer transaction information blocks carrying the instructed amount, the debtor and creditor agents, the value date and settlement details. The key difference is the parties: in pacs.009 the debtor and creditor are the financial institutions themselves, not their customers. There is no customer remittance information in the same sense, although the message can carry references to the underlying business, such as a foreign exchange trade or a treasury transaction, so the receiving bank can reconcile it.

pacs.009 matters in two contexts. First, it is the message that actually moves money between banks in a correspondent chain: when a bank sends a pacs.008 on behalf of a customer, the settlement between the banks behind the scenes often travels as a pacs.009. Second, it is the message used for cover payments, where the customer instruction and the bank settlement travel separately. If you work in treasury, liquidity management or settlements, pacs.009 is the message you will see every day; if you work in customer payments, you will see it less often, but it is still the plumbing underneath your pacs.008.

Reading an ISO 20022 XML message is a skill you build by learning the structure, not by memorising the whole schema. Start at the top. Every message has a Document element, then a message element named after the message type, such as FIToFICstmrCdtTrf for pacs.008. Inside that, the first block is the Group Header, GrpHdr, which carries the message identification, the creation date and time, and the number of transactions. That tells you which message you are looking at and when it was created.

Below the header come the transaction blocks. In pacs.008 these are CdtTrfTxInf blocks, one per payment. Each block reads in a logical order: payment identification, payment type information, amount, charge bearer, then the parties. The debtor is Dbtr, the debtor agent is DbtrAgt, the creditor is Cdtr, the creditor agent is CdtrAgt. Amounts appear as InstdAmt with a currency attribute, and dates appear as ISO dates. If you learn these element names, you can read most of a pacs.008 without a reference manual, because the names are descriptive by design.

In practice, nobody reads raw XML by eye for long. Use an XML viewer or an editor that collapses elements, validate the message against its schema to catch structural errors, and use a mapping tool or a test harness to see the business meaning alongside the XML. The most useful habit is to take a real example message and annotate it: mark the debtor, the creditor, the amount, the value date and the charge bearer, then trace the same payment through its pacs.002 status report. After three or four annotated examples, the structure stops looking like angle brackets and starts reading like a payment.

The ISO 20022 data dictionary is the central catalogue of reusable business concepts that every ISO 20022 message is built from. It defines business components, such as Party, Account, and Payment Instruction, and the data elements inside them, such as name, account number, amount, and currency. Each element has a precise definition, a data type, a format, and a usage rule, so a debtor name means the same thing in a pacs.008, a pain.001, and a camt.053. The dictionary sits above individual messages. Message designers do not invent new fields for every message. They select components from the dictionary and assemble them into a message definition. That reuse is what makes ISO 20022 consistent across payments, securities, trade, cards, and foreign exchange. The dictionary is published in the ISO 20022 Repository and is maintained under ISO Technical Committee 68, with SWIFT acting as the Registration Authority. When a market practice group needs a new concept, it proposes an addition through the formal change process, and the dictionary is updated in a new release. For a practitioner, the dictionary is the first place to check when a field is unclear. If two banks disagree about what an element means, the dictionary definition settles the argument, not a local habit or a legacy MT convention.

A business area is the top level grouping in ISO 20022 that tells you which part of the financial industry a message belongs to. The standard is organised into business areas such as payments, securities, trade services, cards, and foreign exchange. Each business area has a four letter code. Payments uses pacs for payment clearing and settlement, pain for payment initiation, and camt for cash management. Securities uses setr for settlement and reporting, and other codes for corporate actions and custody. The business area code is the first part of a message identifier. In pacs.008.001.02, the letters pacs identify the business area, 008 is the message number inside that area, 001 is the variant, and 02 is the version. Business areas matter because they set the scope of a message and the community that governs it. A payments message is governed by payments market practice groups, while a securities message follows securities rules, even though both share the same data dictionary and the same XML syntax. When you search the repository, you normally start by business area, then narrow to the message you need. That structure keeps a very large standard navigable, and it explains why the same business concept, such as a party or an account, can appear in different business areas with the same definition.

An ISO 20022 message identifier has four parts separated by full stops, for example pacs.008.001.02. The first part is the business area code, a four letter code such as pacs, pain, camt, or admi. The second part is the message number, a three digit number that identifies the specific message inside that business area, such as 008 for a customer credit transfer or 002 for a payment status report. The third part is the variant, normally 001, which distinguishes different uses of the same message number. The fourth part is the version, a two digit number such as 02, 08, or 10, which identifies the release of that message definition. A higher version is not automatically better for a given corridor. Banks agree on one version in their usage guideline, and both sides must use exactly that version. For example, CBPR+ specifies pacs.008.001.08 for cross border payments in its current phase, while SEPA may specify a different version for the same message number. When you read a message, the XML namespace carries the version, so a validator can tell at once whether the file matches the agreed version. If you send version 10 to a counterparty that expects version 08, the message will fail validation even if the business content is correct.

UNIFI is the original name for ISO 20022. It stands for Universal Financial Industry message scheme, and it was the working title used while the standard was being developed in the early 2000s. The name appears in older documents, in the ISO 20022 Repository, and in the formal title of the standard, ISO 20022, Financial services, Universal financial industry message scheme. In practice, the industry now says ISO 20022 and rarely uses UNIFI in conversation, but you will still meet the term in specifications, in training material, and in the names of modelling tools. UNIFI describes the method behind the standard, not a single message. It is a model driven approach. Business experts first model a business process in UML, then define the messages that support that process, then generate the XML schema from the model. That is different from the older MT approach, where the message format came first and the business meaning was described in free text. The UNIFI method is why ISO 20022 messages share components, why the data dictionary exists, and why a new message can be built by reusing existing parts instead of starting from a blank page. If a document says a message is UNIFI compliant, it means the message follows this modelling method and is registered in the ISO 20022 Repository.

The ISO 20022 Repository is the official online library where every registered ISO 20022 message, component, and code list is published. It is maintained by SWIFT as the Registration Authority, under ISO Technical Committee 68. The repository holds the business models, the message definitions, the XML schemas, the data dictionary, and the external code lists. Anyone can browse it at iso20022.org, and banks, vendors, and market infrastructures download the schemas they need for a specific release. The repository is organised by business area, then by message, then by version. For each message you can see the message definition report, which explains the business purpose and the structure, and the XML schema, which is the machine readable file your system validates against. The repository also records the status of each item, such as registered, under development, or withdrawn, so you can tell whether a version is current or superseded. For a practitioner, the repository is the source of truth. A vendor guide, a bank specification, or a training slide can be wrong or out of date, but the repository shows the registered definition. Before you build or test a message, download the schema and the message definition report for the exact version your usage guideline names, and work from those files.

ISO 20022 is maintained by ISO Technical Committee 68, known as TC 68, which is the ISO committee for financial services. TC 68 sets the rules for how the standard is developed, how changes are proposed, and how new messages are approved. It does not write every message itself. Subcommittees and working groups inside TC 68 handle specific areas, and the wider industry proposes new messages through submitting organisations such as SWIFT, national standards bodies, and market infrastructures. SWIFT is the Registration Authority for ISO 20022. That is a separate role from TC 68. The Registration Authority runs the repository, checks that a proposed message follows the modelling rules, publishes the approved definition and schema, and keeps the version history. In practice, a bank or a market practice group that wants a change raises it through its national body or through SWIFT, the proposal is reviewed against the data dictionary, and TC 68 approves the change for a future release. That governance matters because ISO 20022 is a global standard. No single bank, vendor, or country can change a message on its own. The process is slower than a private format change, but it is what gives the standard its stability and its acceptance across payments, securities, and trade.

External code lists are lists of permitted values that ISO 20022 does not fix inside the message definition itself. Instead, the message points to a list that is maintained separately and can be updated without issuing a new version of the message. The best known examples are currency codes, country codes, and payment status codes. Currency uses ISO 4217, so EUR, USD, and GBP come from that external list. Country uses ISO 3166, so GB, IN, and DE come from that list. Other external lists cover return reason codes, charge bearer codes, service levels, and local instrument codes. Each code list has a code, a name, and a set of values with definitions, and the list is published in the repository. A usage guideline can restrict an external list further. For example, a scheme may allow only a subset of service level codes, or a market practice group may require a specific return reason code for a given scenario. When you validate a message, the schema checks the structure, but it does not always check that a code value is on the current external list, so your application must check code values separately. If you use a code that has been withdrawn, or a code from the wrong list, the receiving bank may reject the message with a pacs.002 status of RJCT even though the XML is well formed.

A message definition report is the human readable document that explains one ISO 20022 message. It is published in the repository alongside the XML schema, and it is the document a business analyst reads before writing a specification or a test case. The report starts with the business purpose of the message, the business area it belongs to, and the process it supports. It then shows the message structure as a tree, with each block, each element, its multiplicity, its data type, and its definition. For example, the pacs.008 report shows GroupHeader, PaymentInformation, and CreditTransferTransactionInformation, and it explains which elements are mandatory, which are optional, and which can repeat. The report also lists the business rules, such as the rule that an amount must be present, or that a creditor agent must be identified by BIC or by clearing system member identification. The XML schema is the machine readable version of the same definition, but the schema alone does not explain why a field exists. The message definition report does. When two teams disagree about a field, the report is the reference they should use. Download it for the exact version in your usage guideline, because the structure and the rules can change between versions, and a field that was optional in version 08 may be mandatory in version 10.

ISO 20022 messages are versioned through the last two digits of the message identifier, for example pacs.008.001.08 and pacs.008.001.10 are two versions of the same customer credit transfer message. A new version is issued when the message definition changes, for example when a field is added, a rule is tightened, or an element is made mandatory. The version number increases, but the business area and the message number stay the same, so pacs.008 remains a customer credit transfer in every version. Versions are published in annual releases, and older versions remain in the repository so that banks running an older release can still find the definition they use. A usage guideline always names one version. CBPR+ names a specific version for each phase, SEPA names a specific version for its rulebooks, and a domestic high value system names its own version. That is why version alignment matters so much in migration. Two banks can both be ISO 20022 compliant and still fail to exchange messages if one sends version 10 and the other expects version 08, because the schemas differ. Before a project starts, confirm the agreed version for every message in scope, freeze it in the specification, and test against that exact schema, not against the latest version in the repository.

A usage guideline is a document that narrows the full ISO 20022 message definition down to what one community actually uses. The registered message definition is deliberately broad. It allows many optional fields, many code values, and many combinations, because it must serve many markets. A usage guideline, often called a UG, selects the subset that applies to one scheme, one market infrastructure, or one corridor, and it adds rules that the base definition does not impose. For example, CBPR+ usage guidelines for pacs.008 specify which address format to use, which charge bearer values are allowed, and which elements are mandatory for cross border payments, even though the base pacs.008 definition leaves those elements optional. A usage guideline is published in MyStandards, the SWIFT portal for usage guidelines, and it can be exported as a set of validation rules that a bank loads into its testing tool. When you build an ISO 20022 message, you do not build to the base definition alone. You build to the usage guideline for your scheme and your phase. A message that passes the base schema can still fail a usage guideline check, and a receiving bank will reject it. Always ask which usage guideline and which version applies before you write a single field.

A pacs.002 is a Payment Status Report, sent by a bank or a clearing system to report the status of a payment instruction it received. It is the ISO 20022 reply to a pacs.008, a pacs.009, or a pacs.003. The message has a GroupHeader with the message identification and creation date, and an OriginalGroupInformationAndStatus block that links back to the original message by its MessageIdentification and the number of transactions. Each transaction is reported in a TransactionInformationAndStatus block, with an OriginalInstructionIdentification, a StatusIdentification, and a TransactionStatus element. The status codes are the heart of the message. RJCT means rejected, and the message was not processed. ACCP means accepted for customer profile, and the payment passed initial checks. ACTC means accepted for technical validation, and the payment passed format and syntax checks. ACSC means accepted settlement completed, and the money has settled. ACSP means accepted settlement in process. Other codes include ACCC for accepted with change, PART for partially accepted, and PDNG for pending. A pacs.002 can also carry a StatusReasonInformation block with a reason code, such as a missing field or an invalid account, and additional free text. In practice, a bank watches for RJCT first, because it needs a repair or a return, then for ACSC, because that confirms settlement is complete.

A pacs.003 is a Direct Debit instruction, sent by a creditor bank to a debtor bank through a clearing system to collect money from a debtor account. It is the interbank version of a direct debit, and it follows a mandate that the debtor gave to the creditor. The message has a GroupHeader, a PaymentInformation block with the collection details, and a DirectDebitTransactionInformation block for each collection. The DirectDebitTransactionInformation block carries the amount in InstructedAmount, the creditor in Creditor, the debtor in Debtor, the creditor agent in CreditorAgent, the debtor agent in DebtorAgent, and the mandate reference in DirectDebitTransaction, including MandateRelatedInformation with the MandateIdentification and the DateOfSignature. The PaymentInformation block carries the requested collection date, the local instrument code, and the sequence type, such as first, recurring, final, or one off. A pacs.003 is used in SEPA Direct Debit, where the creditor bank sends it to the debtor bank on the due date, and in other direct debit schemes that use ISO 20022. The debtor bank checks the mandate, checks the account, and either pays or returns the collection with a pacs.004. The status of the collection is reported with a pacs.002, using codes such as RJCT, ACCP, and ACSC.

A pacs.004 is a Payment Return, sent when a payment that was already received cannot be applied and must be sent back to the sender. It is used for a pacs.008 or pacs.009 that reached the creditor agent but could not be credited, for example because the account is closed, the account number is wrong, or the creditor is deceased. The pacs.004 carries a GroupHeader, a PaymentInformation block, and a PaymentReturnTransactionInformation block for each returned payment. That block contains the ReturnReasonInformation element, with a Reason code and AdditionalInformation text. The reason code comes from the external code list for return reasons. Common codes include AC01 for an incorrect account number, AC04 for a closed account number, AC06 for a blocked account, AM05 for a duplicated payment, BE05 for an unknown creditor, MD07 for a missing mandate, and MS03 for a reason not specified. The pacs.004 also carries the OriginalGroupInformation, the OriginalInstructionIdentification, the returned amount in ReturnedInterbankSettlementAmount, and the original debtor and creditor details, so the sender can match the return to the original payment. A return is not the same as a rejection. A rejection is reported with pacs.002 before settlement, while a return is a new payment instruction that moves the money back after settlement.

A pacs.007 is a Payment Reversal, sent to reverse a payment instruction that was already sent but should not have been executed, or to reverse a payment that was executed in error. It is different from a pacs.004 return. A return is sent by the receiving bank because it cannot apply the payment. A reversal is sent by the original sender, or by an agent in the chain, to cancel the effect of a payment that was already instructed. The pacs.007 has a GroupHeader, a PaymentInformation block, and a PaymentReversalTransactionInformation block for each reversed payment. That block carries the OriginalGroupInformation, the OriginalInstructionIdentification, the ReversalReasonInformation with a reason code, and the amount to be reversed. Common reversal reasons include a duplicate payment, a wrong amount, a wrong creditor, and a payment sent after the customer cancelled it. In the MT world, a reversal was often handled by a free format message or a new MT103 with a reversal flag. In ISO 20022, pacs.007 is the structured way to do it, so the receiving bank can match the reversal to the original payment by its identification and can process it automatically. A pacs.007 does not guarantee the money comes back. If the payment already settled and the creditor has withdrawn the funds, the reversal may be rejected and the case becomes an investigation handled with camt.056 and camt.029.

A pacs.008, the Customer Credit Transfer, has three main blocks. GroupHeader, or GrpHdr, carries the MessageIdentification, the CreationDateTime, the NumberOfTransactions, the ControlSum, and the InitiatingParty. PaymentInformation, or PmtInf, carries the PaymentInformationIdentification, the PaymentMethod, the BatchBooking flag, the NumberOfTransactions, the ControlSum, the PaymentTypeInformation with InstructionPriority and ServiceLevel, the RequestedExecutionDate, the Debtor, the DebtorAccount, the DebtorAgent, and the ChargeBearer. CreditTransferTransactionInformation, or CdtTrfTxInf, is repeated for each payment and carries the PaymentIdentification with InstructionIdentification and EndToEndIdentification, the PaymentTypeInformation, the Amount in InstructedAmount and EquivalentAmount, the ChargeBearer, the ChargesInformation in ChrgsInf, the UltimateDebtor, the Debtor, the DebtorAccount, the DebtorAgent, the IntermediaryAgent1, IntermediaryAgent2, and IntermediaryAgent3, the CreditorAgent, the Creditor, the CreditorAccount, the UltimateCreditor, the InstructionForCreditorAgent, the Purpose, and the RemittanceInformation in RmtInf. The structured remittance can carry a CreditorReferenceInformation with a reference such as an invoice number. This structure is why pacs.008 carries far more data than an MT103. Every party, every agent, and every charge is a named element, not a free text line.

The GroupHeader block, written as GrpHdr, is the first block in a pacs.008 and it describes the message as a whole, not any single payment. It carries MessageIdentification, a unique reference the sender assigns to the message, CreationDateTime, the date and time the message was created, and NumberOfTransactions, the count of CreditTransferTransactionInformation blocks in the file. It also carries ControlSum, the total of all the instructed amounts in the message, which the receiver can use to check that no transaction was lost or duplicated. GrpHdr can also carry InitiatingParty, the party that created the message, and GroupReturnInformation if the message is a return. In a bulk file, GrpHdr is what lets a receiving system validate the file before it reads a single payment. If NumberOfTransactions says 50 but the file contains 49 transactions, the file is rejected. If ControlSum does not match the sum of the amounts, the file is rejected. That is a major improvement over MT, where a file level check was often a manual process. When you build a pacs.008, always generate MessageIdentification as a unique value, never reuse an old one, and calculate NumberOfTransactions and ControlSum from the actual transactions in the file, not from a header you copied from a previous file.

The PaymentInformation block, written as PmtInf, is the second block in a pacs.008 and it describes the payment instruction at the batch level. It applies to all the transactions that follow it in that block. PmtInf carries PaymentInformationIdentification, a unique reference for the batch, PaymentMethod, which is normally TRF for a credit transfer, and BatchBooking, a flag that tells the debtor bank whether to book the payments as one batch entry or as separate entries. It also carries NumberOfTransactions and ControlSum for the batch, PaymentTypeInformation with InstructionPriority, such as HIGH or NORM, and ServiceLevel, such as SEPA or URGP, RequestedExecutionDate, the date the debtor wants the payment executed, and the Debtor, DebtorAccount, DebtorAgent, and ChargeBearer that are common to the batch. If every payment in the batch has the same debtor and the same execution date, those details sit in PmtInf and are not repeated in each transaction. If a transaction differs, its own CdtTrfTxInf block can override the batch level value. That structure makes pacs.008 efficient for bulk files. A payroll file with 500 payments can carry the debtor once in PmtInf and list only the creditors and amounts in each CdtTrfTxInf block, instead of repeating the debtor 500 times as an MT file would.

The CreditTransferTransactionInformation block, written as CdtTrfTxInf, is the third block in a pacs.008 and it describes one single credit transfer. A pacs.008 file can contain many CdtTrfTxInf blocks, one for each payment. Each block carries PaymentIdentification with InstructionIdentification, the reference the instructing party assigns, EndToEndIdentification, the reference that travels end to end and is shown to the creditor, and TransactionIdentification, the reference the agent assigns. It carries the Amount in InstructedAmount with a currency attribute, for example EUR 1250.00, and EquivalentAmount if the amount was converted. It carries the ChargeBearer, the ChargesInformation in ChrgsInf with the amount and the agent that took the charge, and the full party chain: UltimateDebtor, Debtor, DebtorAccount, DebtorAgent, IntermediaryAgent1, IntermediaryAgent2, IntermediaryAgent3, CreditorAgent, Creditor, CreditorAccount, and UltimateCreditor. It also carries InstructionForCreditorAgent, Purpose with a code such as SALA for salary or SUPP for supplier payment, and RemittanceInformation in RmtInf, which can be unstructured free text up to 140 characters or structured with CreditorReferenceInformation. When you trace a payment, CdtTrfTxInf is the block you read, because it holds the amount, the parties, and the reference that the creditor sees.

In a pacs.008, the Debtor is the party who owes the money and whose account is debited. The Creditor is the party who is owed the money and whose account is credited. The DebtorAgent is the bank that holds the debtor account and sends the payment instruction. The CreditorAgent is the bank that holds the creditor account and receives the payment. Each party is described in a structured block with Name, PostalAddress, and Identification. The name can be up to 140 characters in ISO 20022, although SEPA limits it to 70 characters. The PostalAddress can be structured, with TownName, Country, and AddressLine, or unstructured during the transition. Identification can carry an OrganisationIdentification with a BIC, a Legal Entity Identifier, or a tax number, or a PrivateIdentification with a date of birth or a customer number. The agents are identified in the same way, normally by BIC in FinancialInstitutionIdentification. A common mistake is to confuse the debtor with the debtor agent. The debtor is the customer, for example Acme Ltd, while the debtor agent is the bank, for example a bank in London with a BIC. The same distinction applies on the creditor side. When a payment fails, the pacs.002 status report names the party or the agent that caused the failure, so a clear distinction in the pacs.008 makes the investigation much faster.

IntermediaryAgent1, IntermediaryAgent2, and IntermediaryAgent3, written as IntrmyAgt1, IntrmyAgt2, and IntrmyAgt3, are the banks in the middle of a payment chain between the debtor agent and the creditor agent. A simple payment has no intermediary. The debtor agent sends directly to the creditor agent. A cross border payment often has one or more intermediaries, because the debtor agent does not hold an account with the creditor agent, or because the payment must pass through a correspondent bank that holds the currency. IntrmyAgt1 is the first intermediary after the debtor agent, IntrmyAgt2 is the next, and IntrmyAgt3 is the last before the creditor agent. Each intermediary is identified by FinancialInstitutionIdentification, normally with a BIC, and each can carry its own account in IntermediaryAgentAccount. The order matters. If you list the intermediaries in the wrong order, the payment may be routed to the wrong bank, or a bank may reject it because it does not recognise the previous agent. In the MT world, intermediaries were carried in field 56a for the intermediary and field 57a for the account with institution. In ISO 20022, the three separate elements make the chain explicit and machine readable, which is why compliance screening and routing can be automated. A payment with three intermediaries is rare, and most cross border payments use one or none.

ChargesInformation, written as ChrgsInf, is the block in a pacs.008 that records the charges taken from a payment and the agent that took them. Each ChrgsInf block carries an Amount with a currency, and a ChargeBearer or a ChargeType, plus the Agent that levied the charge in FinancialInstitutionIdentification. A pacs.008 can carry more than one ChrgsInf block if more than one agent took a charge along the chain. The ChargeBearer element, at the payment level and at the transaction level, tells the chain who pays the charges. The values are DEBT for the debtor, CRED for the creditor, SHAR for shared, and SLEV for the service level agreement. In cross border payments, the charge bearer matters because it decides whether the creditor receives the full amount or the amount less charges. Under CBPR+, the instructed amount and the charges must be transparent, so the creditor agent can reconcile the amount it receives against the amount the debtor sent. In the MT world, charges were carried in field 71A for the charge bearer and field 71F for the sender charges. In ISO 20022, ChrgsInf makes the amount, the currency, and the agent explicit, so a reconciliation system can match charges automatically instead of reading free text. Always populate ChrgsInf when a charge was taken, even if the amount is zero, because a missing block can be read as no charge information.

RemittanceInformation, written as RmtInf, is the block in a pacs.008 that tells the creditor what the payment is for. It has two forms. Unstructured remittance, in Ustrd, is free text up to 140 characters, for example Invoice 7841, March services. Structured remittance, in Strd, is a set of named elements that a creditor system can process automatically. The structured form carries CreditorReferenceInformation with a Type, such as SCOR for a structured creditor reference, and a Reference, such as an RF creditor reference or an invoice number, plus ReferredDocumentInformation with the document number, the document date, and the amount. A pacs.008 can carry one unstructured block or up to 999 structured blocks, but it cannot mix the two forms in the same transaction. The 140 character limit is a hard limit in ISO 20022, and it applies to the total remittance data, not to each line. In the MT world, remittance information was carried in field 70, which allowed only four lines of 35 characters. In ISO 20022, the structured form is the major improvement, because it lets the creditor match the payment to an open invoice without manual work. For SEPA, the structured reference is the RF reference, and the creditor reference must follow the ISO 11649 standard.

A pacs.009 is a Financial Institution Credit Transfer, sent by one financial institution to another to move money between banks, not between a bank and a customer. It is the ISO 20022 replacement for the MT202, which was the general financial institution transfer. A pacs.009 carries a GroupHeader, a PaymentInformation block, and a CreditTransferTransactionInformation block, but the parties are banks, not customers. The debtor and creditor are financial institutions, identified by BIC, and the amount is the interbank settlement amount. The pacs.009 COV variant is a special form of pacs.009 that carries underlying customer information. COV stands for cover. In the MT world, an MT202 COV was used when a bank sent a cover payment for a customer payment that travelled through a different route. The cover carried the customer details so that compliance screening could be done on the real debtor and creditor, even though the cover itself was a bank to bank payment. The pacs.009 COV does the same thing in ISO 20022. It carries the same interbank settlement details as a normal pacs.009, plus an UnderlyingCustomerCreditTransfer block with the debtor, creditor, amount, and remittance information from the original customer payment. That transparency is a core CBPR+ requirement, because it closes the gap where a cover payment hid the underlying customer.

A pacs.010 is an Account Report, sent by an account servicer to an account owner to report the transactions on an account, or to report the account balance. It is a pacs message, but it is not a payment instruction. It is a reporting message that belongs to the payment clearing and settlement business area. The pacs.010 carries a GroupHeader and an AccountReport block with the account identification, the account owner, the account servicer, and the reported transactions or balances. Each transaction in the report carries the amount, the currency, the value date, the booking date, and the references that link it to the original payment, such as the EndToEndIdentification. A pacs.010 is used when a bank needs to give a customer or a correspondent bank a statement of account activity in ISO 20022 format, instead of using a camt.052 or camt.053. The difference is the audience and the business area. A camt.052 or camt.053 is a bank to customer cash management report, while a pacs.010 is a payment system account report, often used between financial institutions. In practice, pacs.010 is less common than camt.053, and many banks use camt messages for all customer reporting. If you receive a pacs.010, read it as a statement, not as an instruction to move money, and reconcile the entries against your own ledger by the references it carries.

A pacs.028 is a Payment Status Request, sent by a bank to ask another bank or a clearing system for the status of a payment it sent earlier. It is the ISO 20022 way to ask, what happened to my payment, in a structured form. The message carries a GroupHeader and an OriginalGroupInformation block that identifies the original message by its MessageIdentification, and an OriginalInstructionIdentification that identifies the specific transaction. It can also carry a StatusRequestIdentification and a RequestedStatus, if the sender wants a specific status. The receiving bank replies with a pacs.002 Payment Status Report, which carries the current status code, such as ACCP, ACSP, ACSC, or RJCT, and a reason if the payment was rejected. In the MT world, a status request was often a free format MT199 or a phone call. In ISO 20022, pacs.028 makes the request machine readable, so the receiving system can look up the payment by its identification and reply automatically. A pacs.028 is used when a payment is overdue, when a customer asks where the money is, or when a reconciliation system cannot match a settlement entry. It does not move money, and it does not change the status of the payment. It only asks for information, and the answer comes back as a pacs.002.

A pain.001 is a Customer Credit Transfer Initiation, sent by a customer to its bank to instruct the bank to make a credit transfer. It is the customer to bank version of a pacs.008. The customer, which can be a company or an individual, sends a pain.001 to its bank, and the bank converts it into a pacs.008 for the interbank leg. The pain.001 has a GroupHeader with MessageIdentification, CreationDateTime, NumberOfTransactions, ControlSum, and InitiatingParty. It has a PaymentInformation block, or PmtInf, with PaymentInformationIdentification, PaymentMethod, BatchBooking, PaymentTypeInformation, RequestedExecutionDate, Debtor, DebtorAccount, and DebtorAgent. It has a CreditTransferTransactionInformation block, or CdtTrfTxInf, for each payment, with PaymentIdentification, Amount in InstructedAmount, ChargeBearer, CreditorAgent, Creditor, CreditorAccount, Purpose, and RemittanceInformation in RmtInf. The structure mirrors pacs.008 deliberately, so a bank can map a pain.001 to a pacs.008 with very little transformation. The difference is the sender. A pain.001 comes from a customer system, such as an ERP or a treasury workstation, while a pacs.008 comes from a bank. In SEPA, a pain.001 is the standard way a corporate customer initiates a SEPA Credit Transfer, and the bank validates it against the SEPA usage guideline before it creates the pacs.008.

A pain.002 is a Customer Payment Status Report, sent by a bank to its customer to report the status of payment instructions the customer sent in a pain.001 or a pain.008. It is the customer facing version of a pacs.002. The bank sends a pain.002 after it validates the customer file, after it executes the payments, and whenever a payment is rejected or fails. The message has a GroupHeader with MessageIdentification and CreationDateTime, an OriginalGroupInformationAndStatus block that links back to the original pain.001 by its MessageIdentification, and a TransactionInformationAndStatus block for each payment. Each transaction block carries the OriginalInstructionIdentification, the StatusIdentification, and the TransactionStatus code. The codes are the same as in pacs.002, including RJCT for rejected, ACCP for accepted, ACTC for accepted after technical validation, ACSP for accepted and settlement in process, and ACSC for accepted and settlement completed. A pain.002 can also carry a StatusReasonInformation block with a reason code and additional text, for example an invalid creditor account or a missing mandatory field. For a corporate customer, the pain.002 is how its ERP knows whether a payment left the bank. If the ERP sends 100 payments and receives a pain.002 with 98 ACSC and 2 RJCT, it can repair the two rejected payments and resend them without rechecking the other 98.

A pain.007 is a Customer Payment Reversal, sent by a customer to its bank to ask the bank to reverse a payment instruction the customer sent earlier. It is the customer to bank version of a pacs.007. A customer sends a pain.007 when it discovers an error after it sent a pain.001, for example a duplicate payment, a wrong amount, a wrong creditor, or a payment that was sent after the underlying invoice was cancelled. The pain.007 carries a GroupHeader, a PaymentInformation block, and a PaymentReversalTransactionInformation block for each payment to be reversed. That block carries the OriginalGroupInformation, the OriginalInstructionIdentification, the ReversalReasonInformation with a reason code, and the amount to be reversed. The bank receives the pain.007, checks whether the original payment has already been executed, and either reverses it or replies with a pain.002 that says the reversal was rejected because the payment already settled. A pain.007 is not a guarantee. If the payment already left the bank and settled at the creditor bank, the customer bank must send a pacs.007 or a camt.056 to the next bank in the chain, and the creditor may need to return the funds with a pacs.004. The pain.007 is the structured start of that process, and it replaces the phone call or email that a customer used to send in the MT world.

A pain.008 is a Customer Direct Debit Initiation, sent by a creditor to its bank to instruct the bank to collect money from debtors by direct debit. It is the customer to bank version of a pacs.003. A company that collects subscriptions, utility bills, or loan repayments sends a pain.008 to its bank, and the bank converts it into a pacs.003 for the interbank leg. The pain.008 has a GroupHeader, a PaymentInformation block, or PmtInf, with PaymentInformationIdentification, PaymentMethod, BatchBooking, PaymentTypeInformation, RequestedCollectionDate, Creditor, CreditorAccount, and CreditorAgent, and a DirectDebitTransactionInformation block for each collection. Each transaction block carries the PaymentIdentification, the InstructedAmount, the DirectDebitTransaction with MandateRelatedInformation, the DebtorAgent, the Debtor, the DebtorAccount, and the RemittanceInformation. The MandateRelatedInformation is essential. It carries the MandateIdentification, the DateOfSignature, and the AmendmentIndicator, so the debtor bank can check that a valid mandate exists. In SEPA, a pain.008 is the standard way to initiate a SEPA Direct Debit, and the scheme distinguishes Core direct debits from B2B direct debits by the local instrument code in PaymentTypeInformation. If the mandate is missing or the sequence type is wrong, the debtor bank returns the collection with a pacs.004.

A pain.009 is a Mandate Initiation Request, sent by a creditor to its bank to ask the bank to set up a new direct debit mandate. A mandate is the authorisation a debtor gives to a creditor to collect money from the debtor account by direct debit. In some schemes, the mandate is held by the creditor and the debtor bank never sees it. In other schemes, the mandate must be registered with the debtor bank before collections can start, and pain.009 is the message that registers it. The pain.009 carries a GroupHeader, a MandateInformation block with the MandateIdentification, the Type of mandate, the DateOfSignature, and the validity dates, plus the Creditor, the CreditorAccount, the Debtor, and the DebtorAccount. It also carries the maximum amount that can be collected, the frequency of collection, and the reason for the mandate. The bank that receives the pain.009 validates the mandate, stores it, and replies with a pain.012 Mandate Acceptance Report if the mandate is accepted, or with a rejection if the mandate is incomplete or the debtor account does not exist. A pain.009 is used in markets where mandates are managed electronically, such as some SEPA countries and some Asian direct debit schemes. In a paper mandate market, the debtor signs a paper form and the creditor stores it, and no pain.009 is sent.

A pain.010 is a Mandate Amendment Request, sent by a creditor to its bank to ask the bank to change an existing direct debit mandate. A mandate is amended when the details of the collection change but the authorisation itself remains valid. Common amendments include a change of creditor name, a change of creditor account, a change of debtor account, a change of the maximum amount, or a change of the collection frequency. The pain.010 carries a GroupHeader, a MandateInformation block with the MandateIdentification of the mandate to be amended, and an AmendmentInformation block that lists each changed field with its old value and its new value. It also carries the Creditor, the Debtor, and the account details after the amendment. The bank validates the amendment, updates its mandate record, and replies with a pain.012 if the amendment is accepted. If the amendment is a change of debtor account, the debtor bank must be notified, because the collections will now be drawn from a different account. A pain.010 is different from a pain.011, which cancels a mandate, and from a pain.009, which creates a new mandate. If the change is so large that the original authorisation no longer applies, for example a change of debtor, the creditor should cancel the old mandate with a pain.011 and create a new one with a pain.009, instead of amending it.

A pain.011 is a Mandate Cancellation Request, sent by a creditor to its bank to ask the bank to cancel an existing direct debit mandate. A mandate is cancelled when the debtor withdraws authorisation, when the contract ends, when the creditor stops trading, or when the debtor closes the account. The pain.011 carries a GroupHeader and a MandateInformation block with the MandateIdentification, the Type of mandate, and the DateOfSignature, plus the Creditor, the Debtor, and the account details. It also carries a CancellationReason, which can be a code or free text, so the bank knows why the mandate was cancelled. Once the bank accepts the cancellation, it stops all future collections under that mandate, and any pain.008 that arrives with that mandate identification will be rejected or returned. The bank replies with a pain.012 to confirm the cancellation. A pain.011 is different from a single payment reversal. A reversal, in pain.007, cancels one collection. A mandate cancellation, in pain.011, cancels the authorisation for all future collections. If a debtor wants to stop one payment but keep the mandate, the creditor should use a reversal or a single collection cancellation, not a pain.011. If the debtor wants to stop all future collections, pain.011 is the correct message.

A pain.012 is a Mandate Acceptance Report, sent by a bank to a creditor to confirm whether a mandate request was accepted or rejected. It is the reply to a pain.009 mandate initiation, a pain.010 mandate amendment, or a pain.011 mandate cancellation. The pain.012 carries a GroupHeader with MessageIdentification and CreationDateTime, an OriginalMessageInformation block that links back to the original pain.009, pain.010, or pain.011 by its MessageIdentification, and an AcceptanceResult block for each mandate. The AcceptanceResult carries the MandateIdentification, the Accepted indicator, and, if the mandate was rejected, a RejectionReason with a code and additional text. Common rejection reasons include an invalid mandate identification, a missing debtor account, a debtor account that is closed, and a mandate that already exists. If the mandate was accepted, the pain.012 confirms that the bank has stored the mandate and that collections can start, or that the amendment or cancellation has been applied. For a creditor, the pain.012 is the signal to update its own mandate system. It should not send a pain.008 collection under a mandate until it has received a pain.012 that says the mandate was accepted, because the debtor bank will return the collection if it has no record of the mandate.

A pain.013 is a Creditor Payment Activation Request, sent by a creditor to its bank to ask the bank to activate a payment service or to activate a specific payment arrangement. It is a less common pain message, and it is used in markets where a creditor must be activated before it can send payment instructions, or where a specific payment product must be enabled for a creditor. The pain.013 carries a GroupHeader, a CreditorInformation block with the Creditor, the CreditorAccount, and the CreditorAgent, and an ActivationRequest block with the service to be activated, the activation date, and any conditions. For example, a creditor that wants to start collecting by direct debit may send a pain.013 to activate the direct debit service, and the bank replies with a pain.014 Creditor Payment Activation Request Status Report. The activation request can also cover a change of service, such as moving from paper mandates to electronic mandates, or adding a new currency to an existing service. In many markets, activation is done by a paper agreement or a portal registration, and no pain.013 is sent. Where it is used, the pain.013 gives the activation a structured, auditable form, so both the creditor and the bank have a record of what was requested, when it was requested, and when it was activated.

A pain.001 and a pacs.008 describe the same credit transfer, but they are sent by different parties at different stages of the payment chain. A pain.001 is sent by a customer to its bank. The customer is the debtor, and the bank is the debtor agent. A pacs.008 is sent by a bank to another bank, or to a clearing system. The debtor agent is the sender, and the creditor agent is the receiver. In a typical corporate payment, the company sends a pain.001 to its bank, the bank validates it, and then the bank creates a pacs.008 to send the payment through the clearing system to the creditor bank. The structures are deliberately similar. Both have a GroupHeader, a PaymentInformation block, and a CreditTransferTransactionInformation block, with the same party names, the same amount elements, and the same remittance information. The differences are small. A pain.001 can carry customer specific details, such as a requested execution date that is a future date, and a batch booking flag that tells the bank how to book the payments. A pacs.008 carries interbank details, such as the interbank settlement amount, the intermediary agents, and the settlement information that only banks need. If you are a corporate treasurer, you work with pain.001. If you are a bank operations analyst, you work with pacs.008, and you receive pain.001 as the input.

A pain.001 and a pain.002 work as a request and a reply in a corporate payment file. The corporate customer sends a pain.001 to its bank with one or more credit transfers. The bank first validates the file against the XML schema and the usage guideline. If the file is valid, the bank sends a pain.002 with a status of ACTC, accepted for technical validation, or ACCP, accepted for customer profile, for each transaction. If a transaction is invalid, the bank sends a pain.002 with a status of RJCT and a StatusReasonInformation block that names the error, such as an invalid creditor account or a missing mandatory field. The bank then executes the accepted payments and sends a second pain.002, or updates the same pain.002, with a status of ACSP when settlement is in process and ACSC when settlement is completed. The corporate ERP reads the pain.002, matches each transaction by its OriginalInstructionIdentification, and updates its own ledger. Payments with ACSC are marked as paid. Payments with RJCT are marked as failed, and the ERP user repairs the data and resends them in a new pain.001. This loop is why pain.002 matters. Without it, the customer would not know whether a payment left the bank, and it would have to check its bank statement manually. With pain.002, the status flows back into the ERP automatically, and reconciliation is a system process, not a manual check.

The common errors in a pain.001 file fall into three groups. First, schema errors, where the XML does not match the schema for the agreed version. Examples include a missing mandatory element, such as Debtor or CreditorAccount, a wrong data type, such as a date in the wrong format, or an amount with too many decimal places. The bank rejects the whole file or the affected transaction with a pain.002 status of RJCT. Second, business rule errors, where the XML is valid but the content breaks a usage guideline rule. Examples include a name longer than 70 characters in SEPA, a remittance longer than 140 characters, a requested execution date in the past, or a charge bearer value that the scheme does not allow. Third, data errors, where the content is well formed but wrong, such as a creditor IBAN that fails the check digit, a BIC that does not exist, or a debtor account that is closed. To fix an error, read the pain.002 StatusReasonInformation, which carries a reason code and additional text. Repair the data in the source system, not by editing the XML by hand, and resend the corrected transaction in a new pain.001 with a new MessageIdentification. Never resend the same MessageIdentification, because the bank will treat it as a duplicate and reject it. Always test a new pain.001 file in the bank test environment before you send it to production.

A camt.029 is a Resolution of Investigation, sent by a bank to close an investigation case that was opened by another bank. It is the reply to a camt.056 payment cancellation request, a camt.110 investigation, or a camt.111 investigation. When a bank receives a request to cancel a payment, to trace a payment, or to investigate a missing payment, it opens a case, checks its records, and then sends a camt.029 to report the outcome. The camt.029 carries a GroupHeader, an Assignment block with the case identification, and a ResolutionOfInvestigation block with the status of the case. The status can be accepted, rejected, or partially accepted, and the message carries a StatusReasonInformation block with a reason code if the request was rejected. For a cancellation request, a camt.029 that says accepted means the payment was cancelled and the funds will be returned. A camt.029 that says rejected means the payment already settled and cannot be cancelled, and the requester must use a return or a claim process instead. In the MT world, an investigation was often handled by MT195, MT196, or MT199 free format messages. In ISO 20022, camt.029 gives the investigation a structured closure, so the requesting bank can update its case system automatically and tell its customer whether the money is coming back.

A camt.052 is a Bank to Customer Account Report, sent by a bank to its customer during the day to report account activity that has happened so far. It is an intraday report, not an end of day statement. A customer can receive several camt.052 messages in one day, each one reporting the transactions booked since the last report. The camt.052 carries a GroupHeader, a ReportHeader with the report identification and the creation date, and an Account block with the account identification, the account owner, and the account servicer. Inside the Account block, the report carries a Balance block with the opening balance, the closing balance, and the available balance, and a Transaction block for each entry. Each transaction carries the amount, the currency, the credit or debit mark, the value date, the booking date, and the references that link it to the original payment, such as the EndToEndIdentification and the MandateIdentification. The difference from a camt.053 statement is timing and finality. A camt.052 is intraday and can be superseded by a later report. A camt.053 is the end of day statement, and it is the legal record of the day. Corporate treasurers use camt.052 to monitor liquidity during the day, and they use camt.053 to reconcile at the end of the day.

A camt.053 is a Bank to Customer Statement, sent by a bank to its customer at the end of the day to report all the transactions booked on an account that day. It is the ISO 20022 replacement for the MT940 statement. The camt.053 carries a GroupHeader, a StatementHeader with the statement identification, the creation date, and the period covered, and an Account block with the account identification, the account owner, and the account servicer. Inside the Account block, it carries a Balance block with the opening balance, the closing balance, and the available balance, and an Entry block for each transaction. Each Entry carries the amount, the currency, the credit or debit mark, the status, the value date, the booking date, the BankTransactionCode, and the EntryDetails. The EntryDetails carry the references that link the entry to the original payment, such as the EndToEndIdentification, the InstructionIdentification, the MandateIdentification, and the RemittanceInformation. That linkage is the major improvement over MT940. In MT940, a statement line carried a short reference and free text, and reconciliation was often manual. In camt.053, the entry carries the structured references from the pacs.008 or pain.001, so an ERP can match the statement line to the original payment automatically. A camt.053 is normally sent once a day, after the end of day processing, and it is the record a customer uses for its legal books.

A camt.054 is a Bank to Customer Debit Credit Notification, sent by a bank to its customer to notify it of a single debit or credit on its account, as soon as the entry is booked. It is the ISO 20022 replacement for the MT900 confirmation of debit and the MT910 confirmation of credit. Unlike a camt.053 statement, which reports all the entries of the day in one file, a camt.054 reports one entry, or a small group of entries, in real time. The camt.054 carries a GroupHeader, a NotificationHeader with the notification identification and the creation date, and an Account block with the account identification. Inside the Account block, it carries an Entry block for each debit or credit, with the amount, the currency, the credit or debit mark, the value date, the booking date, the BankTransactionCode, and the EntryDetails. The EntryDetails carry the references from the original payment, such as the EndToEndIdentification and the RemittanceInformation, so the customer can identify the payment at once. A camt.054 is used when a customer needs to know about a large or urgent entry immediately, instead of waiting for the end of day statement. For example, a treasurer who is waiting for a large customer payment can receive a camt.054 the moment the credit is booked, and can then release goods or pay a supplier without waiting for the statement.

A camt.055 is a Customer Payment Cancellation Request, sent by a customer to its bank to ask the bank to cancel a payment instruction the customer sent earlier. It is the customer to bank version of a camt.056. A customer sends a camt.055 when it discovers an error after it sent a pain.001, for example a duplicate payment, a wrong amount, or a payment to the wrong creditor, and it wants the bank to stop the payment before it is executed. The camt.055 carries a GroupHeader, an Assignment block with the case identification, and an Underlying block that identifies the original payment by its MessageIdentification, its InstructionIdentification, and its EndToEndIdentification. It also carries a CancellationReasonInformation block with a reason code, such as a duplicate payment or a wrong creditor. The bank checks whether the payment has already been executed. If it has not, the bank cancels it and replies with a camt.029 that says the cancellation was accepted. If it has already been executed, the bank sends a camt.056 to the next bank in the chain, and the customer must wait for the reply. A camt.055 is different from a pain.007 reversal. A pain.007 reverses a payment instruction, while a camt.055 cancels a payment instruction. In practice, the two are often used for the same business need, and the bank will advise which message its system expects.

A camt.056 is a FI to FI Payment Cancellation Request, sent by one financial institution to another to ask it to cancel a payment that was already sent. It is the ISO 20022 replacement for the MT192 request for cancellation and the MT195 and MT196 queries. A bank sends a camt.056 when its customer asks it to cancel a payment, when it discovers it sent a duplicate, or when it sent a payment with the wrong amount or the wrong creditor. The camt.056 carries a GroupHeader, an Assignment block with the case identification, and an Underlying block that identifies the original pacs.008 or pacs.009 by its MessageIdentification, its InstructionIdentification, and its EndToEndIdentification. It also carries a CancellationReasonInformation block with a reason code, such as DUPL for a duplicate payment, AM05 for a wrong amount, or CUST for a customer request. The receiving bank checks whether the payment has already been credited to the creditor. If it has not, it cancels the payment and replies with a camt.029 that says the cancellation was accepted, and it returns the funds with a pacs.004. If the payment has already been credited, it replies with a camt.029 that says the cancellation was rejected, and the requesting bank must ask the creditor to return the funds voluntarily. A camt.056 does not move money itself. It only asks for a cancellation, and the reply comes as a camt.029.

A camt.057 is a Notification to Receive, sent by a bank to another bank to tell it that a payment is on its way and that it should expect to receive funds. It is used in markets where the receiving bank needs advance notice of an incoming payment, for example to prepare liquidity, to check compliance, or to match the payment to an expected receipt. The camt.057 carries a GroupHeader, a NotificationHeader, and a NotificationToReceive block with the expected amount, the currency, the value date, the debtor, the creditor, and the references that link the notification to the original payment, such as the EndToEndIdentification. The receiving bank uses the camt.057 to set up an expected receipt in its system, so that when the pacs.008 or pacs.009 arrives, it can match it to the notification and credit it without delay. If the payment does not arrive by the expected date, the receiving bank can follow up with the sending bank. In the MT world, a notification to receive was often sent as an MT210 notice to receive, or as a free format MT199. In ISO 20022, camt.057 gives the notification a structured form, with the amount, the date, and the parties as named elements. A camt.057 does not move money. It is only a notice, and the actual payment still travels as a pacs.008 or a pacs.009.

A camt.058 is a Notification to Receive Cancellation Advice, sent by a bank to cancel a camt.057 notification to receive that it sent earlier. It is used when the payment that was expected will not arrive, for example because the customer cancelled the payment, because the payment was rejected, or because the payment details changed and a new notification must be sent. The camt.058 carries a GroupHeader, a CancellationHeader, and a NotificationToReceiveCancellation block that identifies the original camt.057 by its MessageIdentification and its NotificationIdentification. It also carries a CancellationReasonInformation block with a reason code and additional text, so the receiving bank knows why the expected receipt is no longer valid. The receiving bank removes the expected receipt from its system, so that it does not wait for funds that will never arrive, and so that its liquidity forecast is corrected. If a new payment will be sent with different details, the sending bank sends a new camt.057 with the corrected amount, date, or references. A camt.058 is a short message, because it only needs to identify the notification to be cancelled and give the reason. It does not carry the full payment details again, because those were already carried in the original camt.057, and the cancellation is linked to that message by its identification.

A camt.105 is a Charges Payment Notification, sent by a bank to report charges that it has levied on a payment, or to notify a customer or another bank that charges are due. It is part of the camt charges family, which also includes camt.106, camt.107, camt.108, and camt.109, although the exact use of each message varies by market. The camt.105 carries a GroupHeader, a ChargesInformation block with the charge amount, the currency, the charge type, and the agent that levied the charge, and a reference to the original payment, such as the EndToEndIdentification or the InstructionIdentification. The charge type can be a code for a service charge, a handling charge, or a correspondent bank charge. The message can also carry the account to be debited for the charges, and the value date on which the charges will be taken. In cross border payments, charges are a frequent source of disputes, because the creditor may receive less than the instructed amount if charges were taken along the chain. A camt.105 makes the charges transparent by naming the amount, the currency, and the agent, so the customer can reconcile the charges against its own records. If you receive a camt.105, check the charge amount against the ChargeBearer in the original pacs.008, and raise a query if the charge does not match the agreement.

A camt.106 is a Charges Payment Request, sent by a bank to ask another bank or a customer to pay charges that are due. It is the request side of the charges pair, while camt.105 is the notification side. A bank sends a camt.106 when it has levied a charge and it wants the charge to be paid, for example a correspondent bank charge, a handling charge, or a charge for an investigation. The camt.106 carries a GroupHeader, a ChargesInformation block with the charge amount, the currency, the charge type, and the agent that levied the charge, and a reference to the original payment. It also carries the account to be debited, the value date, and the payment details for the charge itself, so the receiving bank can execute the charge payment. The receiving bank replies with a payment, or with a rejection if the charge is disputed. The difference from camt.105 is the direction and the purpose. A camt.105 notifies a party that a charge has been levied or will be levied. A camt.106 asks a party to pay a charge. In practice, the two messages are used in different markets, and some markets use only one of them. Before you build a charges flow, check the usage guideline for your market to see which message it expects, and what charge type codes it allows. Using the wrong message will cause the charge to be rejected or ignored.

The camt.107, camt.108, and camt.109 messages are the ISO 20022 messages for cheque processing. A camt.107 is a Cheque Presentment Notification, sent by a bank to notify another bank that a cheque has been presented for payment. A camt.108 is a Cheque Presentment Cancellation Notification, sent to cancel a presentment notification that was sent in error. A camt.109 is a Cheque Presentment Advice, sent to advise a bank that a cheque has been presented and to give the details needed to process it. Each message carries a GroupHeader, a cheque identification block with the cheque number, the cheque amount, the currency, the drawer, the drawee, and the payee, and a reference to the account to be debited. The messages are used in markets where cheques are still cleared electronically through ISO 20022, instead of through a paper clearing system. In many markets, cheques are in decline, and these messages are rarely used, but they remain in the standard for markets that still process cheques. If you work in a market that has moved to electronic payments, you may never see a camt.107, camt.108, or camt.109. If you work in a market that still clears cheques, these messages replace the paper presentment advice and the free format messages that were used in the MT world to report a cheque presentment.

A camt.110 is an Account Reporting Investigation, sent by a customer or a bank to ask for an investigation into an account report, such as a camt.052 or a camt.053. It is used when a statement line is missing, when a balance is wrong, or when an entry cannot be matched to a payment. The camt.110 carries a GroupHeader, an Assignment block with the case identification, and an Investigation block that identifies the original report by its MessageIdentification and its ReportIdentification, and the specific entry by its amount, its value date, and its references. It also carries a description of the problem, such as a missing credit or an incorrect amount. The receiving bank opens a case, checks its records, and replies with a camt.029 Resolution of Investigation, or with a corrected camt.052 or camt.053. A camt.110 is different from a camt.111, which investigates a payment, not a report. A camt.110 is about the reporting, while a camt.111 is about the payment itself. In the MT world, an account reporting query was often sent as an MT195 or MT199 free format message. In ISO 20022, camt.110 gives the query a structured form, so the bank can match it to the exact report and the exact entry, and can close the case with a structured reply.

A camt.111 is a Payment Investigation, sent by a bank or a customer to ask for an investigation into a payment that is missing, delayed, or incorrect. It is the ISO 20022 replacement for the MT195 and MT196 payment queries. A bank sends a camt.111 when its customer asks where a payment is, when a payment has not arrived by the expected date, or when a payment arrived with the wrong amount or the wrong creditor. The camt.111 carries a GroupHeader, an Assignment block with the case identification, and an Investigation block that identifies the original payment by its MessageIdentification, its InstructionIdentification, and its EndToEndIdentification. It also carries the amount, the currency, the value date, the debtor, the creditor, and a description of the problem, such as a missing payment or an incorrect amount. The receiving bank checks its records, traces the payment through its system, and replies with a camt.029 Resolution of Investigation, which says whether the payment was found, whether it was credited, or whether it was rejected and returned. A camt.111 does not move money. It only asks for information, and the reply comes as a camt.029. If the investigation finds that the payment was sent to the wrong account, the case becomes a cancellation or a return, handled with a camt.056 or a pacs.004.

MyStandards is the SWIFT portal where banks, market infrastructures, and vendors publish and read ISO 20022 usage guidelines. It is the place where a usage guideline lives, not just as a PDF, but as a set of machine readable rules that can be downloaded and loaded into a testing tool. A bank that wants to send a pacs.008 to another bank first finds the usage guideline for that corridor in MyStandards, reads which elements are mandatory, which code values are allowed, and which rules apply, and then builds its message to match that guideline. MyStandards also lets a community publish a new version of a usage guideline, and lets users compare two versions to see what changed. For CBPR+, the usage guidelines for pacs.008, pacs.009, pacs.002, and the other cross border messages are published in MyStandards, and they are updated for each phase of the migration. A vendor that builds a payment hub will import the MyStandards usage guideline into its validation engine, so that a message that fails the guideline is caught before it is sent. For a practitioner, MyStandards is the second source of truth after the repository. The repository gives you the base message definition, and MyStandards gives you the usage guideline that tells you how your community actually uses that message. Always check MyStandards before you start a project, because a usage guideline can be updated without a new version of the base message.

To read a CBPR+ usage guideline, start with the message you need, for example pacs.008, and open its usage guideline in MyStandards. The guideline shows the message structure as a tree, with each element marked as mandatory, optional, or conditional. It also shows the multiplicity, which tells you how many times an element can repeat, and the data type, which tells you the format. Next, read the rules that the guideline adds on top of the base definition. For example, the CBPR+ pacs.008 guideline requires a structured address or a hybrid address, it restricts the charge bearer values, and it requires the ultimate debtor and ultimate creditor when they are known. The guideline also lists the code values that are allowed, and it marks some codes as not allowed for cross border payments. Then read the examples. A CBPR+ usage guideline normally includes sample messages that show a correct pacs.008 for a common scenario, such as a customer payment with one intermediary. Use those samples as a template, but do not copy them blindly, because your payment may need different fields. Finally, download the validation rules from MyStandards and load them into your testing tool. A message that passes the base XML schema can still fail the usage guideline, and the only way to catch that before you send it is to validate against the guideline rules, not just against the schema.

The coexistence period is the phase of the ISO 20022 migration when both MT messages and ISO 20022 MX messages are accepted on the SWIFT network. It began in March 2023, when SWIFT started accepting ISO 20022 messages for cross border payments alongside MT messages. During coexistence, a bank could send an MT103 or a pacs.008, and the receiving bank had to be able to accept both. That was deliberate, because it let banks migrate at their own pace, instead of forcing every bank in the world to switch on the same day. The coexistence period was planned to end in November 2025, when MT103 and MT202 would no longer be allowed for cross border payments. In practice, SWIFT extended a few MT messages for about one more year, but the core MT103 and MT202 messages are no longer allowed after November 2025. The coexistence period also had phases. Phase 2 began in November 2023, and phase 3 began in November 2024, with each phase adding more mandatory ISO 20022 data and tightening the rules. For a bank, coexistence meant running two formats in parallel, maintaining two sets of validation rules, and building translation logic to convert MT to MX and MX to MT. That dual running was expensive, which is why the industry wanted coexistence to end, even though the end date was extended for a few messages.

After November 2025, the core MT messages for cross border payments are no longer allowed on the SWIFT network. An MT103 customer payment and an MT202 financial institution transfer will be rejected if they are sent after the deadline. SWIFT extended a few MT messages for about one more year, to give banks more time to migrate the less common messages, but the main payment messages, MT103 and MT202, are not in that extension. The remaining MT messages were due to be retired in the November 2026 release, but SWIFT deferred those changes on 27 August 2026 and the deferred release is scheduled for 12 June 2027, when the remaining MT messages are retired and the ISO 20022 format becomes the only format for cross border payments. After November 2025, a bank that still sends an MT103 will receive a rejection from SWIFT, and it will have to resend the payment as a pacs.008. A bank that receives a pacs.008 must be able to process it, including the structured address, the richer remittance information, and the ultimate debtor and creditor details. Banks that are not ready face operational risk, because they cannot send or receive cross border payments in the old format. That is why the migration was phased, with March 2023, November 2023, and November 2024 as milestones, so that banks had time to build, test, and go live before the November 2025 deadline. If your bank still has MT traffic after the deadline, treat it as an urgent exception, not as a normal flow.

A translation rule is a documented rule that tells a system how to convert a field from an MT message to an ISO 20022 MX message, or from MX back to MT, during the coexistence period. Because MT and MX do not have the same fields, translation is not a simple copy. A translation rule defines the source field, the target element, the transformation, and what to do when the source field has no exact target. For example, MT field 50K, the ordering customer, maps to the Debtor block in a pacs.008, with Name in field 50K line 1 and PostalAddress in the following lines. MT field 59, the beneficiary customer, maps to the Creditor block. MT field 70, remittance information, maps to RemittanceInformation in Ustrd, but only the first 140 characters are carried, and the rest is truncated. A translation rule also covers code values. MT field 71A, the charge bearer, maps to ChargeBearer in pacs.008, with OUR mapping to DEBT, BEN mapping to CRED, and SHA mapping to SHAR. Translation rules are published by SWIFT in the CBPR+ translation guide, and each bank must implement them in its payment hub. A bank that writes its own translation rules without following the SWIFT guide will produce messages that other banks cannot read, or will lose data in translation. Always test translation with real MT messages from your own traffic, not just with sample messages.

MT to MX mapping works in practice through a translation engine in a bank payment hub or in a SWIFT service. When a bank receives an MT103, the engine reads each MT field, looks up the translation rule for that field, and writes the value into the corresponding MX element in a pacs.008. Field 20, the transaction reference, maps to InstructionIdentification. Field 32A, the value date, currency, and amount, maps to the InterbankSettlementDate, the currency, and the InterbankSettlementAmount. Field 50K maps to Debtor, field 59 maps to Creditor, field 52A maps to DebtorAgent, field 57A maps to CreditorAgent, field 56A maps to IntermediaryAgent1, field 70 maps to RemittanceInformation, and field 71A maps to ChargeBearer. The engine also handles fields that have no direct MX equivalent. For example, MT field 72, sender to receiver information, is mapped to InstructionForCreditorAgent or to additional information, depending on the content. The engine must also handle the reverse direction, MX to MT, when the receiving bank is still on MT. In that direction, data loss is a risk, because MX carries more data than MT can hold. A 140 character name in MX must be cut to 35 characters per line in MT, and structured address data must be flattened into unstructured lines. That is why banks were told to migrate to MX as soon as possible, instead of relying on translation for a long time.

Truncated data is data that is cut off when a message is translated from ISO 20022 MX to MT, because MT cannot hold as much data as MX. The best example is a name. ISO 20022 allows a party name of up to 140 characters, while MT allows only 35 characters per line and four lines for a party. When a pacs.008 with a 140 character name is translated to an MT103, the translation engine must cut the name to fit the MT field, and the rest of the name is lost. The same happens with remittance information. MX allows 140 characters, while MT field 70 allows four lines of 35 characters, so a long remittance is truncated. Structured address data is also truncated, because MT has no structured address fields, and the address must be flattened into unstructured lines. Truncation is a risk because the receiving bank may not be able to identify the debtor or creditor from a truncated name, and compliance screening may fail. CBPR+ introduced a rule that truncated data must be flagged, so that the receiving bank knows the data was cut and can ask for the full data if it needs it. The long term solution is not to translate MX to MT at all, but to send MX end to end, so that no data is lost. That is one reason the coexistence period was time limited, and why MT was retired for the core payment messages.

HVPS+ is the High Value Payments Plus group, a market practice group that defines how ISO 20022 is used for high value payment systems, such as real time gross settlement systems and other domestic high value systems. While CBPR+ defines ISO 20022 for cross border payments on the SWIFT network, HVPS+ defines ISO 20022 for domestic high value payments, such as Fedwire in the United States, CHAPS in the United Kingdom, and TARGET2 in Europe. The HVPS+ group publishes usage guidelines for pacs.008, pacs.009, pacs.002, and the other messages used in high value systems, and it harmonises the way those systems use ISO 20022, so that a payment that starts in one high value system can be understood in another. The group is made up of central banks, market infrastructures, and commercial banks, and it works with SWIFT and with ISO Technical Committee 68. The HVPS+ usage guidelines are similar to CBPR+, but they have differences that reflect the needs of a domestic high value system, such as the need for a settlement date, a priority flag, and a liquidity indicator. If you work on a high value payment system, you must follow the HVPS+ usage guideline for that system, not the CBPR+ guideline, because the two guidelines name different mandatory fields and different code values for the same message.

CBPR+ and HVPS+ are two market practice groups that define how ISO 20022 is used, but for different payment types. CBPR+ stands for Cross Border Payments and Reporting Plus. It defines ISO 20022 for cross border payments that travel on the SWIFT network, such as a payment from a bank in London to a bank in Singapore. HVPS+ stands for High Value Payments Plus. It defines ISO 20022 for domestic high value payments that settle in a real time gross settlement system, such as a payment from one UK bank to another UK bank through CHAPS, or a payment from one US bank to another through Fedwire. The messages are the same, pacs.008, pacs.009, and pacs.002, but the usage guidelines differ. CBPR+ focuses on cross border needs, such as structured addresses, ultimate debtor and creditor details, and compliance screening data. HVPS+ focuses on domestic high value needs, such as settlement priority, liquidity management, and central bank settlement. A bank that sends both cross border and domestic high value payments must follow both guidelines, and must not mix them. A pacs.008 built to the CBPR+ guideline may fail validation in a high value system that expects the HVPS+ guideline, and vice versa. The two groups work together to harmonise where they can, but they remain separate because the business needs of cross border and domestic high value payments are different.

Market practice groups are industry groups that define how ISO 20022 is used in a specific market, scheme, or corridor. The base ISO 20022 message definition is deliberately broad, so that it can serve many markets. A market practice group narrows it down to what its members actually need, and it publishes a usage guideline that its members must follow. The best known market practice groups are CBPR+ for cross border payments, HVPS+ for high value payments, and the SEPA groups for euro payments. Other groups cover securities, trade, and cards, and there are national groups for domestic payments in countries such as India, Japan, and Australia. A market practice group is made up of banks, market infrastructures, central banks, and vendors, and it works with SWIFT as the Registration Authority and with ISO Technical Committee 68. The group agrees on which fields are mandatory, which code values are allowed, which address format to use, and which version of a message to use. It also agrees on testing rules and on a migration timeline. For a practitioner, the market practice group is the authority for your corridor. If you send a payment to a SEPA country, you follow the SEPA usage guideline. If you send a cross border payment on SWIFT, you follow the CBPR+ usage guideline. Following the base definition alone is not enough.

Banks test ISO 20022 messages in three stages before they go live. First, they test in their own test environment, where they validate a message against the XML schema and against the usage guideline rules from MyStandards. They check that the message is well formed, that all mandatory elements are present, and that code values are on the allowed lists. Second, they test with SWIFT in the SWIFT test environment, where they send test messages to SWIFT and receive test replies. SWIFT provides test cases for CBPR+, including a pacs.008 with a structured address, a pacs.008 with a hybrid address, a pacs.009 COV, and a pacs.002 rejection. The bank must pass those test cases before SWIFT allows it to send live ISO 20022 messages. Third, they test with their counterparties, in bilateral testing, where two banks send test payments to each other and check that the payments are received, validated, and processed correctly. That stage catches issues that schema validation cannot, such as a wrong intermediary order, a missing ultimate creditor, or a charge bearer that the counterparty does not expect. Banks also run parallel testing, where they send the same payment in MT and in MX and compare the results, to make sure the translation is correct. Only after all three stages pass does a bank move a corridor to live ISO 20022.

The ISO 20022 Document Centre is the section of the ISO 20022 website where the formal documents for the standard are published. It holds the ISO 20022 standard itself, the modelling rules, the registration rules, and the governance documents that explain how the standard is maintained. It also holds the message definition reports, the data dictionary, and the external code lists, although those are also available through the repository. The Document Centre is different from MyStandards. MyStandards holds usage guidelines for specific communities, such as CBPR+ and HVPS+, while the Document Centre holds the base standard and the rules that all communities must follow. For a practitioner, the Document Centre is useful when you need to understand the rules behind the standard, for example how a new message is proposed, how a change is approved, or how the data dictionary is structured. It is less useful for day to day message building, where the repository and MyStandards are the main tools. If you are writing a specification, a test plan, or a migration plan, cite the Document Centre for the governance and the modelling rules, and cite the repository and MyStandards for the message definition and the usage guideline. That separation keeps your references clear and auditable.

The 12 CPMI harmonised requirements are a set of data requirements published by the Committee on Payments and Market Infrastructures, known as CPMI, to harmonise how ISO 20022 is used in cross border payments. CPMI is part of the Bank for International Settlements, and it published the requirements to make sure that the same payment data is available end to end, so that compliance screening, fraud detection, and reconciliation can be done automatically. The 12 requirements cover the identification of the debtor and creditor, the identification of the debtor agent and creditor agent, the identification of the ultimate debtor and ultimate creditor, the structured address, the purpose of the payment, the remittance information, the charges, the settlement information, and the references that link a payment to its original instruction. Each requirement lists the ISO 20022 elements that must be present, and the format they must follow. For example, one requirement says that the debtor and creditor must be identified by name and by a structured address, and another says that the ultimate debtor and creditor must be present when they are different from the debtor and creditor. CBPR+ usage guidelines implement the 12 requirements, so a bank that follows CBPR+ is also following CPMI. If you are building a payment system, use the 12 requirements as a checklist, and test each one with a real payment, not just with a sample message.

A structured address in ISO 20022 is an address where each part is a separate named element, such as StreetName, BuildingNumber, PostCode, TownName, and Country. A structured address is machine readable, so a compliance system can check the town and country automatically, and a routing system can use the post code. An unstructured address is an address where the whole address is carried in free text lines, in AddressLine elements, with no separation into street, town, and country. An unstructured address is easy to write, but it is hard for a system to read, because the system must parse free text to find the town and country. A hybrid address is a mix of the two. It carries the town and country as structured elements, TownName and Country, and the rest of the address as unstructured AddressLine elements. During the ISO 20022 migration, hybrid addresses were allowed as a transition, so that banks that could not yet produce a fully structured address could still send a payment. SWIFT had planned to reject messages with unstructured addresses for cross border payments from November 2026, so that only structured addresses, and hybrid addresses that carry TownName and Country as structured elements, would be accepted. That requirement was deferred on 27 August 2026, with a new date to be announced by December 2026, so unstructured addresses are not rejected on that ground alone until the new date is set. Banks should still convert their customer address data to structured form, and validate TownName and Country before they send a pacs.008, because the requirement is coming and structured data already improves screening and routing.

If you send an MT message after the ISO 20022 deadline for that message, SWIFT will reject it and the payment will not be delivered. For the core payment messages, MT103 and MT202, the deadline was November 2025, and those messages are no longer allowed for cross border payments. A bank that sends an MT103 after the deadline will receive a rejection from SWIFT, normally with a network error that says the message type is no longer supported, and it will have to resend the payment as a pacs.008. A few MT messages were extended for about one more year, but SWIFT deferred the November 2026 changes on 27 August 2026, so the extension and the final retirement now follow the deferred release scheduled for 12 June 2027. A bank that sends one of those extended messages will still be accepted, but only until the extension ends. After that final release, all remaining MT messages for cross border payments will be retired. Sending an MT after the deadline also creates operational risk. The payment will be delayed, the customer will complain, and the bank may have to pay compensation for the delay. It also creates compliance risk, because the MT message does not carry the structured address, the ultimate debtor and creditor, and the richer remittance data that ISO 20022 requires. If your bank still has MT traffic after the deadline, stop it at the source, convert the payment to a pacs.008, and test the pacs.008 in the SWIFT test environment before you send it live.

The same pacs.008 version can behave differently on CBPR+ and on SEPA because the two schemes apply different market practice rules on top of the same ISO 20022 base standard. The base standard defines the message structure, the elements and the data types, but it does not decide which elements are mandatory, which code values are allowed, or how long a field may be. Each scheme publishes its own usage guidelines that tighten the base standard for its own market. CBPR+, which governs cross-border payments on the SWIFT network, had planned to require structured addresses from November 2026, but SWIFT deferred that requirement on 27 August 2026 and a new date is to be announced by December 2026; it mandates specific party identification, and allows a wider set of charge bearer options and remittance information formats. SEPA, which governs euro payments inside the Single Euro Payments Area, has its own rulebook, its own implementation guidelines, and its own limits, such as the maximum amount for an instant payment and the specific use of the creditor and debtor elements. A pacs.008 that passes validation on SEPA can therefore fail on CBPR+ because a mandatory CBPR+ element is missing, or because a code value allowed in SEPA is not allowed in CBPR+. A bank must validate each payment against the rulebook of the scheme it is using, not just against the base schema.

The Legal Entity Identifier, known as the LEI, is a 20 character code that uniquely identifies a legal entity, such as a company, a fund or a government body, anywhere in the world. In payment messages, the LEI is carried in the party identification elements, for example in the debtor or the creditor identification, so that the receiving bank and the screening system know exactly which legal entity is involved. This matters because company names are ambiguous: two companies can have similar names, and a name alone is not enough to screen a payment reliably. An LEI removes that ambiguity, because each code maps to one entity in the global LEI database, with its registered name, address and ownership information. Regulators in several markets now require the LEI in payment messages for certain transactions, and the CBPR+ usage guidelines encourage its use for cross-border payments. For a business analyst, the practical work is to decide when the LEI is mandatory, when it is optional, and what happens when a customer does not have one: the payment may still be sent with a name and address, but the bank must record the gap and consider whether to ask the customer to obtain an LEI. The LEI does not replace the account number or the BIC; it adds a layer of identification that makes screening, reconciliation and regulatory reporting more reliable.

ISO 20022 timestamps carry a UTC offset that states the difference between the local time and Coordinated Universal Time, known as UTC, and getting the offset wrong can change the meaning of a payment. A timestamp written as 2026-05-12T14:30:00+02:00 means 14:30 in a time zone that is two hours ahead of UTC, which is 12:30 UTC. The same moment written in London time would be 2026-05-12T13:30:00+01:00 during daylight saving, and in UTC it would be 2026-05-12T12:30:00Z, where Z means zero offset. The three forms describe the same instant, but a system that reads only the clock time and ignores the offset will treat them as three different times, which can break cutoff checks, value dating and reconciliation. The common errors are recording a local time without an offset, using the wrong offset after a daylight saving change, and mixing timestamps from different time zones in the same report. The safe practice is to store every timestamp in UTC and to convert it to local time only when it is displayed to a user. When a payment message carries a creation date and time, the analyst should confirm which time zone the sender used, check that the offset is present and correct, and test the daylight saving changeover, because a one hour error on the day the clocks change can push a payment past its cutoff.

An XSD pattern validation error occurs when a value in an ISO 20022 message does not match the regular expression, known as a pattern, that the schema defines for that element. Every element in the schema has a data type, and many types carry a pattern that restricts the allowed characters, the length or the format. For example, the IBAN element uses a pattern that allows only two letters followed by two digits and then up to 30 alphanumeric characters, so an IBAN containing a space or a hyphen fails validation. The currency code element uses a pattern that allows only three uppercase letters, so a lowercase code such as eur fails, and the amount element uses a pattern that allows only digits with an optional decimal point. When a message fails pattern validation, the receiving system rejects it before any business processing, and returns an error that names the element and the pattern that was violated. The most common causes are spaces or special characters copied from a spreadsheet, lowercase codes, and values that exceed the maximum length. To fix the error, the analyst traces the failing value to its source, corrects the source data or the transformation rule, and retests with the corrected value. Pattern errors are easy to prevent with a validation step before the message is sent.

Market practice rules are the additional rules that a payment scheme or a market adds on top of the ISO 20022 base standard, and they decide how the standard is actually used. The base standard defines the message structure, the elements and the data types, but it leaves many choices open: which elements are mandatory, which code values are allowed, how long a field may be, and how an element should be populated in a given scenario. A market practice document, such as the CBPR+ usage guidelines or the SEPA implementation guidelines, answers those questions for its own market, and a payment that follows the base standard but ignores the market practice rules will be rejected by the scheme. For example, the base standard allows both structured and unstructured addresses, but CBPR+ had planned to require structured addresses from November 2026; SWIFT deferred that requirement on 27 August 2026, with a new date to be announced by December 2026, so until the new date is set a payment with only an unstructured address is not rejected on that ground alone. Similarly, the base standard allows many charge bearer codes, but a market may allow only two of them. For a business analyst, the practical rule is to validate every message against both layers: the base schema first, to catch format errors, and then the market practice rules, to catch business errors. The two layers must be kept separate in documentation, so that a change in market practice does not look like a change in the standard.

UPI, Unified Payments Interface, is India instant payment system, built by the National Payments Corporation of India and launched in 2016. It lets any two bank accounts in India exchange money instantly, 24 hours a day, using a mobile phone. The user does not need the recipient bank account number and IFSC: they can pay using a Virtual Payment Address such as name@bank, a mobile number, or a QR code. Behind the simple front end is a real time settlement system that moves money between banks within seconds.

A UPI payment follows a clear sequence. The payer enters the recipient identifier and the amount in their UPI app, then authorises the payment with their UPI PIN. The payer bank, known as the remitter bank, sends the transaction to the UPI switch, which routes it to the beneficiary bank. The beneficiary bank credits the account and confirms back through the switch, and the payer sees a success message. Settlement between the banks happens through their accounts with the Reserve Bank of India, on a deferred net basis across settlement cycles during the day.

UPI works because it separates the addressing from the banking. The Virtual Payment Address is a layer on top of bank accounts, so a user can link several bank accounts to one app and choose which to pay from. It also supports collect requests, where a merchant asks a customer to approve a payment, and recurring mandates through UPI AutoPay. The scale is what makes UPI remarkable: it processes billions of transactions a month, from street vendors to large merchants, and it has become the default way India pays. For learners, the key point is that UPI is an overlay system: it does not replace bank accounts, it makes them instantly reachable by phone.

IMPS, NEFT and RTGS are the three main electronic fund transfer systems in India, and they differ in speed, settlement model and use case. IMPS, Immediate Payment Service, is instant and available 24 hours a day, including weekends and holidays. A transfer is processed in seconds, and it works through mobile banking, internet banking and ATMs. It is designed for retail payments where the sender wants the money to arrive immediately.

NEFT, National Electronic Funds Transfer, works in batches. Transfers are collected and settled in half hourly batches during operating hours, so a payment sent now may arrive within a couple of hours rather than seconds. There is no minimum or maximum amount for NEFT in principle, and it is widely used for retail and corporate payments where immediate arrival is not critical. RTGS, Real Time Gross Settlement, is different again: each transaction is settled individually and immediately in the books of the Reserve Bank of India, with no netting. RTGS is intended for high value transactions, with a minimum of two lakh rupees, and it is used by banks, corporates and government for large transfers where finality and certainty matter most.

The simplest way to choose is by urgency and value. For a small instant payment at any hour, use IMPS or UPI. For a routine transfer where a short delay is acceptable, NEFT is fine. For a large value transfer where you need immediate, irrevocable settlement, use RTGS. All three move money between bank accounts in India, and all three are operated under the oversight of the Reserve Bank of India, but their settlement mechanics are what make each one right for a different job.

SEPA, the Single Euro Payments Area, is the framework that makes euro payments work the same way across Europe. Before SEPA, a payment from Germany to France was a cross border payment with different formats, timelines and charges from a domestic payment. SEPA harmonised that: within the SEPA area, which covers the eurozone plus several other European countries, a euro payment is treated the same whether it stays inside one country or crosses a border. The framework is governed by the European Payments Council and supported by EU regulation.

SEPA defines three main payment instruments. SEPA Credit Transfer, SCT, is the standard euro credit transfer, where the payer instructs their bank to send money to the beneficiary. SEPA Direct Debit, SDD, lets a creditor collect money from a debtor account with a mandate, which is how subscriptions and utility bills are collected across Europe. SEPA Instant Credit Transfer, SCT Inst, is the real time version, settling within seconds. All three use ISO 20022 message formats, which is one reason SEPA was an early large scale adopter of the standard.

For a learner, the important idea is that SEPA is not a single system but a set of rules, standards and schemes that banks and clearing systems implement. The actual clearing and settlement happens through systems such as STEP2 and the Eurosystem TARGET service, but the customer experience is defined by SEPA: one account, one format, the same timing and the same charging rules across the whole area. SEPA is the model many other regions study when they design their own harmonised payment areas.

SEPA Instant, formally SEPA Instant Credit Transfer or SCT Inst, is the real time version of the SEPA Credit Transfer. It is a scheme from the European Payments Council that lets euro payments settle within seconds, 24 hours a day, 365 days a year, between accounts in the SEPA area. The target is a maximum of ten seconds from the payer bank sending the payment to the beneficiary bank confirming receipt, and most payments complete much faster. The scheme went live in 2017 and has grown steadily as more banks and payment service providers joined.

The mechanics are straightforward in concept and demanding in practice. The payer bank sends an SCT Inst instruction, the beneficiary bank must respond within the time limit, confirming that the account exists and the funds are credited or rejecting the payment with a reason. Settlement between banks happens through clearing systems such as the Eurosystem TIPS service, which settles in central bank money in real time, or through other clearing arrangements. Because the payment is instant and irrevocable, banks must run strong fraud and sanctions checks in milliseconds, and they must be available around the clock, which requires significant investment in systems and operations.

SEPA Instant matters because it changed expectations. Once instant euro payments exist, customers and corporates expect all payments to be instant, and the European Instant Payments Regulation now requires banks in the euro area to offer instant payments. The scheme has a transaction limit that has been raised over time, and it supports the same ISO 20022 message formats as the rest of SEPA. For anyone comparing instant payment systems globally, SCT Inst is the European reference point, and its design choices around speed, irrevocability and 24 hour operation are the ones other systems are measured against.

FedNow is the United States instant payment service operated by the Federal Reserve, launched in July 2023. It lets banks and credit unions in the US send and receive instant payments 24 hours a day, 365 days a year, with settlement in central bank money. A payment sent through FedNow is credited to the beneficiary within seconds and is final and irrevocable, which makes it suitable for everything from person to person transfers to business supplier payments and bill pay.

The service works through participating financial institutions. A customer instructs a payment through their bank, the bank sends it into the FedNow Service, the service validates and routes it to the receiving bank, and the receiving bank credits the beneficiary and confirms. Settlement happens immediately between the banks master accounts at the Federal Reserve, so there is no end of day netting delay and no settlement risk hanging over the payment. FedNow also supports request for payment, where a biller asks a customer to pay, and it carries ISO 20022 message formats, which aligns it with the global standard.

FedNow is significant because the US previously had no central bank operated instant payment system; the private sector RTP network from The Clearing House filled that gap from 2017. FedNow gives smaller banks and credit unions a Federal Reserve operated route to instant payments, and it is designed to interoperate with the broader US payment landscape rather than replace existing systems. The transaction limit has been set at a level that covers most retail and small business payments, and it is expected to grow. For learners, FedNow is the American answer to the global instant payment trend, and its launch marked the point where instant payments became a core part of US payment infrastructure.

Fedwire is the United States real time gross settlement system operated by the Federal Reserve. It is the system through which banks settle large value payments in central bank money, one transaction at a time, with immediate finality. When a bank sends a payment through Fedwire, the Federal Reserve debits the sending bank master account and credits the receiving bank master account, and the payment is final at that moment. There is no netting and no waiting for an end of day batch.

Fedwire is used for high value and time critical payments: interbank transfers, settlement of securities transactions, corporate treasury payments, and large customer payments where certainty matters. It operates during Federal Reserve business hours, which is a key difference from instant payment systems that run around the clock. Each payment is processed individually, and banks must have sufficient funds or intraday credit in their master account for the payment to settle. The system carries rich payment information, and it has been migrating to the ISO 20022 message format, aligning it with the global standard.

The name Fedwire is sometimes confused with FedNow, but the two are different tools. Fedwire is the wholesale, high value, gross settlement system that has underpinned the US financial system for decades. FedNow is the newer retail instant payment service for smaller, round the clock payments. A corporate treasurer sending a multi million dollar settlement would use Fedwire; a customer paying a supplier on a Sunday would use FedNow. Understanding which one applies is a basic test of US payments knowledge.

CHIPS, the Clearing House Interbank Payments System, is a private sector US payment system operated by The Clearing House, and it is the main system for large value US dollar payments. It is used heavily for international payments: when a bank outside the US sends dollars to a bank inside the US, the payment very often clears through CHIPS. It also handles domestic large value transfers between US banks. CHIPS is a net settlement system, which is its defining difference from Fedwire.

In CHIPS, payments are not settled one by one in central bank money as they arrive. Instead, they are queued, offset against each other where possible, and settled on a net basis through a prefunded account at the Federal Reserve. This netting is efficient: it lets banks settle a large volume of payments with less liquidity than gross settlement would require. The system runs during US business hours, and at the end of the day the net positions are settled finally. Banks that use CHIPS must prefund their positions and manage their liquidity carefully, because a payment only releases when the netting and funding allow it.

CHIPS and Fedwire together form the backbone of US dollar clearing. Fedwire is the Federal Reserve operated gross settlement system; CHIPS is the private sector net settlement system. For cross border payments, the choice matters: a dollar payment routed through CHIPS will follow CHIPS rules, cut off times and liquidity arrangements, and the beneficiary bank will see it as a CHIPS payment. Anyone working in US dollar correspondent banking needs to know both systems, how they differ, and why a payment might be routed through one rather than the other.

Faster Payments is the United Kingdom real time payment system, launched in 2008 and operated by Pay.UK. It lets people and businesses send sterling payments between UK bank accounts in seconds, 24 hours a day, 365 days a year. It is the system behind most everyday instant payments in the UK: paying a friend, paying a bill, or a business paying a supplier. When you make an instant transfer from your UK banking app, it is almost certainly travelling over Faster Payments.

The system works through participating banks and payment service providers. The payer bank sends the payment instruction, the system validates and routes it, the beneficiary bank credits the account and confirms, and the payer sees the result within seconds. Settlement between banks happens on a net basis across the day through their accounts at the Bank of England, with several settlement cycles. The transaction limit is high enough to cover most retail and small business payments, and it has been raised over time; very large payments still go through CHAPS instead.

Faster Payments matters because it was one of the first national instant payment systems in the world, and it proved that real time retail payments could work at national scale. It changed customer expectations in the UK: standing orders, one off transfers and business payments that once took days now arrive in seconds. For learners, the key facts are its age, its operator Pay.UK, its 24 hour availability, and its role as the retail instant system sitting alongside CHAPS for high value and Bacs for bulk scheduled payments.

CHAPS, the Clearing House Automated Payment System, is the United Kingdom high value payment system, operated by the Bank of England. It is the UK equivalent of Fedwire: a real time gross settlement system in which each payment is settled individually and immediately in central bank money, with finality at the moment of settlement. It is used for payments where value, certainty and timing matter most, such as house purchases, large corporate payments, and settlement between financial institutions.

A CHAPS payment is typically high value, and there is no upper limit in principle, although banks set their own limits and charges. The payer bank sends the instruction, the Bank of England debits the payer bank settlement account and credits the beneficiary bank settlement account, and the beneficiary bank credits its customer. The payment is irrevocable once settled. CHAPS operates during Bank of England business hours on working days, which is why a house completion payment is scheduled for a weekday and why same day CHAPS payments have a cut off time.

CHAPS is the system behind the moments that matter most in UK finance. When someone buys a house, the solicitor sends the purchase funds by CHAPS so the seller receives them with certainty on completion day. When a bank settles a large obligation with another bank, it uses CHAPS. The system migrated to ISO 20022 message formats, aligning it with the global standard. The contrast with Faster Payments is the point to remember: Faster Payments is the instant retail system for everyday payments, CHAPS is the gross settlement system for high value payments where finality in central bank money is non negotiable.

UPI, SEPA Instant and FedNow are three of the most important instant payment systems in the world. They share one goal, money moving between accounts in seconds, around the clock, but they were built in different contexts and differ in design. UPI is India's system, operated by the National Payments Corporation of India, and it is an overlay that addresses bank accounts through Virtual Payment Addresses, mobile numbers and QR codes. SEPA Instant is the European scheme from the European Payments Council, running across the SEPA area in euro. FedNow is the US service operated by the Federal Reserve, launched in 2023.

The differences start with addressing. UPI is the most consumer friendly at the front end: a phone number or a QR code is enough to pay, and it works for tiny merchant payments as well as large transfers. SEPA Instant and FedNow are more bank centric: the user pays from their bank account, addressed by IBAN in Europe or by account in the US. Settlement differs too: UPI settles between banks on a deferred net basis through the Reserve Bank of India, SEPA Instant can settle in real time through TIPS, and FedNow settles immediately in central bank money at the Federal Reserve.

Policy choices differ too. UPI was built for financial inclusion and scale, with a low cost model that made digital payments viable for street vendors. SEPA Instant was built for harmonisation across many countries, with a common scheme and ISO 20022 messages. FedNow was built to give every US bank, including small community banks, access to instant payments. The lesson is that instant is not one system: it is a set of design choices about addressing, settlement, cost and governance, and each national answer reflects its own banking structure and policy goals.

ACH stands for Automated Clearing House. It is a domestic electronic payment system that processes large volumes of low value transactions in batches rather than one by one. Instead of settling each payment immediately, an ACH collects payment instructions from many banks and customers, sorts them, and processes them in files at scheduled times during the day.

Typical ACH transactions include salary credits, direct debits for utility bills, insurance premiums, loan instalments, and government benefit payments. Because the system is batch based, it is cheap to run, which makes it ideal for recurring and high volume payments where same second settlement is not needed.

The trade off is speed. An ACH payment usually takes one to two business days to reach the beneficiary, depending on the cut off time and the number of processing cycles that day. If a payment is submitted after the last cycle, it waits until the next business day. That is why ACH is a poor choice for urgent payments, but an excellent choice for predictable bulk payments. In India, the closest equivalents are NACH for bulk debits and credits and NEFT for individual electronic transfers, both of which follow the same batch and deferred settlement logic.

NACH stands for National Automated Clearing House. It is operated by the National Payments Corporation of India (NPCI) and is the system Indian banks use for bulk electronic payments, both credits and debits. It replaced the older Electronic Clearing Service and brought all bulk clearing under one national platform with standard formats.

NACH Credit is used when one payer sends money to many people at once. The classic example is a company paying salaries to thousands of employees, or a government department disbursing pensions and subsidies. The payer sends one file with all the beneficiaries, and NACH distributes the credits to the respective banks.

NACH Debit works the other way. A company that collects recurring payments, such as an insurer collecting premiums, a lender collecting EMIs, or a utility collecting bills, presents debit instructions against customers who have given a mandate. The mandate is the customer's standing authorisation, and it can be paper based or electronic through e-mandate. NACH Debit is therefore the backbone of recurring collections in India.

Settlement under NACH is deferred and batch based, usually taking one business day. That makes it cheap and reliable for bulk volumes, but unsuitable for urgent individual payments, where IMPS or UPI would be used instead.

A real-time payment system is one in which a payment is cleared and settled within seconds, at any time of day, including weekends and holidays. The payer gets immediate confirmation, the beneficiary's account is credited almost instantly, and the funds are available for use right away. There is no waiting for the next batch cycle or the next business day.

India's best known examples are UPI and IMPS. UPI lets a person pay a merchant or another individual using a mobile phone and a virtual payment address, while IMPS moves money directly between bank accounts using account number and IFSC or a mobile number and MMID. Both operate 24 by 7 and settle in seconds.

Real-time systems work because they are built on instant messaging between banks and a settlement mechanism that can handle continuous flow, often through prefunded settlement accounts or frequent net settlement cycles at the central bank. The design challenge is liquidity and risk: since payments never stop, banks must always have enough funds available, and fraud controls must work in milliseconds rather than hours.

The practical result is that real-time systems have become the default for person to person transfers, merchant payments, and urgent transfers, while batch systems remain the choice for bulk and scheduled payments where immediate settlement is not worth the cost.

Speed differs sharply across India's domestic payment systems because each was designed for a different purpose. UPI and IMPS are the fastest: both settle in seconds, 24 hours a day, seven days a week, including holidays. A UPI payment from a phone typically reaches the beneficiary in under ten seconds, and IMPS is similar. These are the systems to use when the money must arrive now.

NEFT is the next tier. It processes payments in half hourly batches during the day, so a payment usually reaches the beneficiary within a couple of hours, and often within 30 minutes if it catches the next batch. Since December 2019 NEFT also operates 24 by 7, so it no longer stops at the end of the banking day, but it is still batch based rather than instant.

RTGS is also fast, but it is built for large value. Payments submitted during RTGS hours are settled individually in real time, typically within minutes, and the system operates for most of the day and into the evening on working days. It is not a 24 by 7 retail system.

NACH is the slowest of the group. Bulk credits and debits are processed in daily cycles and usually take one business day to settle. Cheques remain the slowest of all, taking one to three days depending on clearing location. The rule of thumb is simple: instant for UPI and IMPS, hours for NEFT, minutes for RTGS, and a day for NACH.

Each Indian payment system has its own limits, and they reflect the purpose it was built for. UPI has a general per transaction limit of 1 lakh rupees for most person to person and merchant payments, with higher limits of up to 5 lakh rupees for certain categories such as tax payments, hospitals, and educational institutions. Banks may also set a lower daily limit for their own customers, so the effective limit can vary.

IMPS has a per transaction limit of 5 lakh rupees. That makes it suitable for urgent mid value transfers, but not for very large payments. NEFT has no maximum limit at all, which is why it is often used for large transfers that are not urgent enough to need RTGS. There is no minimum either, so NEFT can carry very small amounts.

RTGS is designed for high value payments and has a minimum of 2 lakh rupees per transaction, with no upper limit. It is the system used for large business payments, property settlements, and interbank transfers.

NACH has no fixed per transaction ceiling in the same way, because it is a bulk system, but individual debit mandates carry a maximum amount set in the mandate itself, and banks apply their own per item caps. Cheque limits depend on the account and the bank. The practical guidance is: UPI or IMPS for small and urgent, NEFT for large and non urgent, RTGS for 2 lakh rupees and above, and NACH for bulk recurring flows.

UPI settlement happens in two layers, authorisation and settlement, and they do not happen at the same moment. When a payer confirms a UPI payment, the payer bank checks the balance, debits the payer account, and sends an authorisation through the National Payments Corporation of India, known as NPCI. NPCI routes the instruction to the payee bank, which credits the payee account. The customer sees the money move in seconds, but the banks have not yet settled with each other at that point. Settlement between banks happens through the Reserve Bank of India, using accounts that banks hold with the central bank. NPCI nets the transactions between banks over a settlement cycle and produces a net position for each bank. A bank that has sent more than it received pays the difference, and a bank that received more is paid the difference. Settlement cycles run several times a day, so the net positions are cleared regularly rather than once overnight. This design is why UPI can feel instant to customers while the underlying interbank money moves in batches. If a bank fails to fund its net debit position, the settlement can be delayed, and NPCI and the Reserve Bank of India have procedures to manage that shortfall. Reconciliation teams in each bank match every UPI transaction against the NPCI settlement file to confirm that customer credits and debits line up with the net settlement amount.

A Virtual Payment Address, known as a VPA, is a unique identifier that lets a person receive UPI payments without sharing bank account details. A typical VPA looks like a name followed by an at sign and a handle, for example debarghya@okaxis. The handle identifies the payment service provider or bank that issued the VPA, such as okaxis, okhdfcbank, or ybl. Behind the VPA, the issuing bank maintains a mapping table that links the VPA to one specific bank account, including the account number and the Indian Financial System Code, known as IFSC. When a payer enters a VPA, the payer bank asks NPCI to resolve it. NPCI routes the request to the bank that owns the handle, which returns the account holder name and confirms the mapping. The payer sees the name before confirming, which is an important fraud check. One bank account can have more than one VPA, and a person can create different VPAs in different UPI apps for the same account. A VPA can also be changed or deleted, and the mapping is updated immediately. If the underlying account is closed, the VPA stops working. Merchants use VPAs in the same way, and a collect request can be sent to a VPA so the payer only has to approve it. The mapping keeps account numbers private while still giving the payment system a precise destination.

A UPI payment follows a fixed sequence from initiation to confirmation. First, the payer opens a UPI app and enters the payee details, which can be a VPA, a mobile number, a QR code, or an account number with IFSC. Second, the payer enters the amount and an optional remark, then confirms the payment instruction. Third, the app asks for the UPI PIN, a four or six digit secret that the payer set when registering. Fourth, the payer bank validates the PIN, checks that the account has enough funds, and debits the payer account. Fifth, the instruction travels through NPCI, which acts as the central switch. NPCI validates the message format, checks the payee details, and routes it to the payee bank. Sixth, the payee bank credits the payee account and sends a success response back through NPCI to the payer bank. Seventh, both banks send confirmation messages to their customers, and the payer app shows a success screen with a transaction reference number. The whole flow normally completes in a few seconds. If any step fails, for example a wrong PIN, insufficient funds, or a timeout at the payee bank, the transaction is declined or marked as failed. If the payer account was debited but the payee was not credited, the system raises an exception and the money is reversed to the payer, usually within a defined time window.

The National Payments Corporation of India, known as NPCI, is the organisation that operates and governs India's major retail payment systems. It was set up by the Reserve Bank of India and the Indian Banks Association, and it functions as an umbrella organisation for retail payments. NPCI operates UPI, IMPS, the National Automated Clearing House known as NACH, the National Financial Switch for ATMs, RuPay cards, Bharat BillPay, and AePS, the Aadhaar Enabled Payment System. Its role has three parts. First, it builds and runs the central switching infrastructure that routes payment instructions between banks in real time. Second, it sets the operating rules, message standards, and technical specifications that member banks and payment apps must follow. Third, it manages settlement files, dispute handling, and certification of new participants. NPCI does not hold customer accounts and does not itself move central bank money. Settlement between banks happens in Reserve Bank of India money, based on net positions that NPCI calculates. NPCI also works with the Reserve Bank of India on limits, fraud controls, and new products such as UPI Lite and UPI AutoPay. Banks connect to NPCI systems, test their integration, and are certified before they go live. When a transaction fails or a dispute arises, NPCI provides the transaction records and the dispute framework that banks use to resolve it.

UPI person to person, known as P2P, and UPI person to merchant, known as P2M, use the same rails but serve different purposes and follow different rules. A P2P payment is a transfer between two individuals, for example sending money to a friend or family member, splitting a bill, or paying rent to a landlord. The payer initiates the payment, enters the payee VPA or mobile number, and the money moves directly from one personal account to another. A P2M payment is a payment from a customer to a business, for example paying at a shop, a restaurant, an online store, or a utility provider. The merchant presents a QR code or a payment link, and the customer scans it and approves the payment. The key differences are in limits, charges, and settlement. P2M transactions can have higher per transaction limits for certain categories, and merchants may use specialised acquiring arrangements. P2P transactions are typically free for the customer, while merchants may pay a fee to their acquiring bank or payment aggregator, although many small merchant transactions remain free under current policy. Refunds work differently too. A P2M payment can be reversed by the merchant through a refund flow, while a P2P payment generally cannot be reversed by the sender and must be returned voluntarily by the receiver. Reporting also differs, because banks and NPCI track P2P and P2M volumes separately to understand retail usage and merchant adoption.

UPI limits are set by NPCI and the Reserve Bank of India, and individual banks can set lower limits inside those caps. For most person to person payments, the general per transaction limit is 1 lakh rupees, and the daily limit is also commonly 1 lakh rupees, although some banks allow higher daily totals. For certain verified merchant categories, the per transaction limit is higher. Payments to hospitals, educational institutions, and for initial public offerings, known as IPOs, can go up to 5 lakh rupees per transaction. Capital market, insurance, and government securities transactions can also have a 2 lakh rupee limit in some cases. The number of transactions per day is typically capped at 20 by many banks, although this varies. UPI Lite has much lower limits, with a maximum balance of 2,000 rupees in the Lite wallet and a per transaction limit of 500 rupees. UPI AutoPay allows recurring mandates up to 15,000 rupees per transaction without an additional PIN, and higher amounts need a one time PIN approval. Banks can also set their own per transaction limits below the NPCI caps, so two customers of different banks may see different limits. Limits are reviewed periodically as volumes grow, and NPCI publishes updates when caps change. Customers should check their own bank app for the exact limit that applies to them.

UPI Lite is a simplified version of UPI designed for small value, high frequency payments where entering a PIN every time would be slow and inconvenient. It works like a small on device wallet inside a UPI app. A user loads money into the UPI Lite balance from a bank account, up to a maximum balance of 2,000 rupees. Each UPI Lite payment can be up to 500 rupees, and no UPI PIN is needed for these small payments. This makes it ideal for buying tea, paying for a bus ticket, or making small purchases at a local shop. Because no PIN is required, the risk is limited by the low balance cap and the low per transaction cap. If the phone is lost, the maximum exposure is the balance in the Lite wallet, which cannot exceed 2,000 rupees. UPI Lite transactions are processed without going through the full UPI authorisation flow for every payment, which reduces load on bank systems and makes payments faster. The Lite balance is held by the issuing bank, and the user can add funds or disable UPI Lite at any time. Transactions made through UPI Lite still appear in the app transaction history, but they may not appear as individual entries in the bank account statement, because only the loading of funds is debited from the bank account. UPI Lite X, an extension, allows offline payments using near field communication for very small amounts.

UPI AutoPay is the recurring payment feature of UPI that lets customers set up automatic debits for subscriptions and regular bills. A customer can create a mandate for services such as streaming subscriptions, insurance premiums, loan instalments, mutual fund systematic investment plans, and utility bills. To set up a mandate, the customer selects the merchant, the amount or maximum amount, the frequency, and the start and end dates. The customer then approves the mandate with a UPI PIN. Once the mandate is active, the merchant can collect the payment on each due date without asking the customer to approve every time. For amounts up to 15,000 rupees per transaction, no additional authentication is needed at the time of collection. For amounts above 15,000 rupees, the customer receives a pre debit notification and must approve the payment with a PIN before it is collected. The customer can view, modify, pause, or revoke a mandate at any time from the UPI app, and the merchant is notified when a mandate is revoked. AutoPay reduces failed payments caused by forgotten renewals, and it gives customers control because they can set a maximum amount and an end date. Banks and NPCI monitor AutoPay mandates to prevent misuse, and a mandate cannot collect more than the approved maximum amount.

IMPS and UPI are both instant payment systems operated by NPCI, but they differ in design, addressing, and user experience. IMPS, the Immediate Payment Service, was launched in 2010 and works through bank channels such as internet banking, mobile banking, and ATMs. It identifies the payee by account number and IFSC, or by a Mobile Money Identifier, known as MMID, linked to a mobile number. UPI, launched in 2016, works through a dedicated app layer and identifies the payee by a Virtual Payment Address, a mobile number, or a QR code, without exposing the account number. Technically, UPI is built as an application programming interface layer on top of IMPS infrastructure. UPI uses IMPS rails for the actual movement of funds between banks, but it adds a standardised API, a VPA addressing system, collect requests, and merchant flows. IMPS transactions are usually initiated by the payer alone, while UPI supports both pay requests and collect requests, where the payee asks the payer to approve a payment. UPI also supports intent flows, QR codes, and in app payments that IMPS does not. The user experience differs too. IMPS requires the payer to add a beneficiary and often wait for activation, while UPI allows an immediate payment to a new VPA. Both settle instantly and operate 24 hours a day, 7 days a week, but UPI is the customer facing layer and IMPS is the underlying instant settlement mechanism.

NEFT, the National Electronic Funds Transfer system, is a batch based system operated by the Reserve Bank of India. Unlike UPI and IMPS, which settle each transaction immediately, NEFT collects transactions into batches and settles them at fixed intervals. Since December 2019, NEFT has operated 24 hours a day, 7 days a week, including holidays. Batches are settled every half hour, so there are 48 settlement batches in a day. A transaction submitted by a customer is included in the next available batch. If a customer submits a payment at 10:05, it will normally be settled in the 10:30 batch, and the payee bank credits the account shortly after. The exact credit time depends on the payee bank processing speed, but it is typically within one to two hours of initiation. Before December 2019, NEFT operated only during banking hours on working days, with hourly batches. The move to half hourly batches and round the clock operation made NEFT much more useful for scheduled payments. There is no minimum or maximum amount for NEFT, although individual banks may set their own limits. NEFT is well suited for salary payments, vendor payments, and other bulk or scheduled transfers where immediate settlement is not essential. If a transaction cannot be credited, for example because the account details are wrong, the amount is returned to the originating bank within the next batch cycle.

RTGS, the Real Time Gross Settlement system, is India's high value payment system operated by the Reserve Bank of India. It settles each transaction individually and in real time, rather than netting transactions together in a batch. The word gross means each payment is settled for its full amount, one by one, in central bank money. RTGS is designed for large value, time critical payments such as interbank transfers, government securities settlements, and large corporate payments. The minimum amount for an RTGS transaction is 2 lakh rupees. There is no maximum amount, so transactions worth crores of rupees can be settled through RTGS. RTGS operates 24 hours a day, 7 days a week, including holidays, since December 2020. Before that, it operated only during banking hours. A customer initiates an RTGS payment through internet banking or a branch, providing the payee account number, IFSC, amount, and purpose. The payer bank debits the customer and sends the instruction to the Reserve Bank of India, which debits the payer bank settlement account and credits the payee bank settlement account immediately. The payee bank then credits the payee account. Because settlement is final and irrevocable once processed, RTGS is used where certainty and immediacy matter most. Fees are typically higher than NEFT or UPI, reflecting the high value and real time nature of the service.

NACH, the National Automated Clearing House, is NPCI system for bulk electronic payments in India, covering both credits and debits. NACH Credit is used for bulk payments from one payer to many payees, such as salaries, pensions, dividends, and government subsidies. NACH Debit is used for bulk collections from many payers to one payee, such as loan instalments, insurance premiums, utility bills, and mutual fund systematic investment plans. Mandates are the heart of NACH Debit. A mandate is an authorisation given by a customer to a bank and a merchant, allowing the merchant to debit the customer account on a recurring basis. The mandate specifies the amount, which can be fixed or a maximum amount, the frequency, the start date, and the end date. Mandates can be created on paper or electronically, known as e mandates. An e mandate is created through internet banking, a debit card, or Aadhaar based authentication, and it is registered with the customer bank through NPCI. Once registered, the merchant submits a debit file to NPCI on each due date, NPCI routes the debits to the respective banks, and the banks debit the customer accounts. If a debit fails because of insufficient funds, the transaction is returned with a reason code, and the merchant can retry it. Customers can cancel a mandate at any time through their bank, and the merchant cannot collect after cancellation.

The Reserve Bank of India, known as RBI, is the central bank of India and the ultimate authority for the payment systems of the country. Its role is set out in the Payment and Settlement Systems Act of 2007, which gives RBI the power to regulate, supervise, and authorise payment systems. RBI operates the two most important settlement systems, RTGS and NEFT, and it provides the settlement accounts that banks use to settle with each other. It also oversees NPCI, which operates UPI, IMPS, NACH, and other retail systems. RBI sets policy on limits, charges, customer protection, and fraud prevention. For example, it defines the rules for failed transaction refunds, including the requirement that money debited in a failed transaction must be reversed within a defined time, failing which the bank must pay compensation to the customer. RBI issues licences to payment system operators, payment aggregators, and prepaid payment instrument issuers. It sets capital, governance, and data localisation requirements for these entities. RBI also runs the Ombudsman scheme for digital transactions, which gives customers a route to complain if a bank does not resolve a payment issue. Through its monetary policy and its operation of settlement accounts, RBI also manages liquidity in the banking system so that payment systems can settle smoothly each day.

CTS, the Cheque Truncation System, is the system that allows cheques to be cleared electronically in India without the physical cheque travelling to the paying bank. Before CTS, a cheque deposited in one city had to be physically transported to the bank branch where the drawer held the account, which could take days. Under CTS, the bank where the cheque is deposited scans the cheque and captures an image, including the magnetic ink character recognition code, known as MICR, the account number, and the amount. The image and the data are sent electronically through a clearing house to the paying bank. The paying bank verifies the signature and the account details from the image and decides whether to honour or return the cheque. Clearing under CTS normally happens on the same day or the next working day, depending on when the cheque is deposited. CTS was rolled out nationally from 2010 and is now the standard method for cheque clearing across India. The system is operated by NPCI, under the oversight of the Reserve Bank of India. CTS has several benefits. It is faster, it reduces the risk of cheques being lost in transit, and it lowers the cost of clearing. Customers can also see the scanned image of a cleared cheque in their internet banking. Cheques that are dishonoured, for example because of insufficient funds, are returned electronically with a reason code.

Bharat BillPay, officially known as Bharat Bill Payment System or BBPS, is the centralised bill payment system of India operated by NPCI Bharat BillPay Limited. It provides a single platform where customers can pay bills for many categories of billers, including electricity, water, gas, telecom, broadband, direct to home television, loan repayments, insurance premiums, school fees, and municipal taxes. Before BBPS, each biller had its own payment channels, and customers had to visit different websites or outlets for different bills. BBPS standardises the process. Billers register on the platform through a biller operating unit, and customers access it through a customer operating unit, which can be a bank app, a wallet, or a physical agent outlet. A customer selects the biller, enters the consumer number, and the system fetches the bill amount directly from the biller in real time. The customer pays through UPI, a card, internet banking, or cash at an agent. The payment is confirmed instantly and a receipt is generated. BBPS also supports recurring bill payments through mandates and provides a standardised complaint and dispute process. Agents in small towns and villages can collect bill payments on behalf of customers who do not use digital channels. This makes BBPS an important part of financial inclusion, because it brings a wide range of billers onto one interoperable platform.

AePS, the Aadhaar Enabled Payment System, is a bank led payment system that allows customers to carry out basic banking transactions using their Aadhaar number and biometric authentication. It was developed by NPCI to support financial inclusion, especially for people in rural areas who may not have a smartphone or a debit card. A customer visits a banking correspondent, known as a business correspondent, who carries a micro ATM or a point of sale device with a fingerprint scanner. The customer provides the Aadhaar number, selects the bank, and authenticates with a fingerprint or an iris scan. The system verifies the identity against the Aadhaar database and allows the customer to check the balance, withdraw cash, deposit cash, or transfer funds to another Aadhaar linked bank account. AePS transactions are processed in real time through NPCI, and the customer account is debited or credited immediately. The daily transaction limit for AePS is generally 10,000 rupees per transaction, although banks may set their own limits. AePS is widely used for disbursing government subsidies and welfare payments, because the money can be withdrawn by the beneficiary at a local agent using only a fingerprint. It is also used for cash withdrawals in areas where ATMs are scarce. Security depends on biometric authentication, so customers must protect their Aadhaar details and report any unauthorised transaction promptly.

Indian banks reconcile UPI transactions by matching three sets of records every day. The first set is the bank internal transaction log, which records every UPI debit and credit on customer accounts, with the transaction reference number, the amount, the time, and the status. The second set is the NPCI settlement file, which lists every UPI transaction that NPCI processed for that bank, grouped by settlement cycle, and the net settlement amount that the bank owes or is owed. The third set is the Reserve Bank of India settlement account statement, which shows the actual movement of central bank money for each settlement cycle. Reconciliation teams compare these records to find breaks, such as a transaction that was debited from a customer but does not appear in the NPCI file, or a transaction that appears in the NPCI file but was not credited to the customer. Automated reconciliation systems match most transactions by reference number and amount. Unmatched items are investigated manually. Common causes include timeouts, duplicate messages, and system downtime at one bank. Banks also reconcile UPI transaction fees, failed transaction reversals, and dispute cases. The reconciliation must be completed daily, because settlement is final and any error must be detected quickly. Regulators expect banks to have strong reconciliation controls, and audit teams review the process regularly. Good reconciliation is what allows a bank to trust that its customer balances and its settlement position are both correct.

When a UPI payment fails but money is debited from the payer account, the customer is protected by a defined reversal process. First, the payer should check the transaction status in the UPI app. A transaction can show as failed, pending, or successful. If it shows as failed and the account was debited, the bank is expected to reverse the debit automatically. Under Reserve Bank of India rules, the reversal should happen within a short time, typically within one working day for most failed UPI transactions, and the bank must pay compensation if it misses the deadline. If the transaction shows as pending, the system is still waiting for a response from the payee bank. The status is usually resolved within a few hours, and the money is either credited to the payee or reversed to the payer. The customer does not need to do anything while the transaction is pending. If the reversal does not happen automatically, the customer should raise a complaint with the payer bank through the app, internet banking, or a branch, quoting the transaction reference number. The bank investigates using NPCI transaction records. If the bank does not resolve the complaint within 30 days, the customer can escalate to the Reserve Bank of India Ombudsman for digital transactions. Customers should never send the money again until the first transaction is resolved, because a duplicate payment may succeed and create a double payment that is harder to recover.

FedNow works as a real time settlement service operated by the Federal Reserve, and each payment moves in seconds from payer to payee. First, a customer initiates a payment through a bank app or online banking, for example sending money to a friend or paying a supplier. Second, the payer bank checks the balance, verifies the payee details, and sends a payment message to the FedNow Service in ISO 20022 format. Third, FedNow validates the message, checks that both banks are participants, and routes it to the payee bank. Fourth, the payee bank confirms that it can accept the payment and that the payee account is valid. Fifth, FedNow debits the master account of the payer bank at the Federal Reserve and credits the master account of the payee bank, in central bank money, immediately. Sixth, FedNow sends a confirmation to both banks, and the payee bank credits the payee account and notifies the customer. The whole process normally completes in a few seconds, and it operates 24 hours a day, 7 days a week, including weekends and holidays. FedNow also supports request for payment messages, where a biller asks a customer to pay, and the customer approves it. The service launched in July 2023, and the initial transaction limit was 500,000 dollars, with banks able to set lower limits. If a payment cannot be completed, for example because the payee bank rejects it, FedNow returns an error and no settlement occurs.

The FedNow participation model allows different types of financial institutions to join in different roles, depending on their size and technical capability. A bank or credit union can join as a full participant, sending and receiving payments directly through the FedNow Service. To do this, it must hold a master account at a Federal Reserve Bank, connect to the FedNow system, and meet operational and security requirements. A smaller institution that does not want to build a direct connection can join through a service provider, such as a core banking processor or a technology vendor, which connects to FedNow on its behalf. The institution still holds its own master account, but the technical connection is managed by the provider. A third model is the correspondent model, where an institution settles through another bank that acts as its correspondent. The correspondent holds the master account and settles FedNow payments for the smaller institution. FedNow also allows participants to join as receive only at first, so they can accept incoming payments while they build the capability to send. Participants must agree to the FedNow operating rules, maintain sufficient liquidity in their master account, and monitor their systems around the clock. The Federal Reserve provides onboarding support, testing environments, and certification. As of 2024, hundreds of banks and credit unions had joined, and the network continues to grow as more service providers add FedNow support.

Fedwire settles payments in real time and in gross, which means each payment is settled individually for its full amount, with finality, in central bank money. A Fedwire payment starts when a customer instructs a bank to send a wire, for example for a house purchase, a large corporate payment, or a settlement between financial institutions. The sending bank debits the customer account and sends a Fedwire message to the Federal Reserve. The message contains the sender and receiver details, the amount, and any reference information. The Federal Reserve checks that the sending bank has enough funds in its master account, or enough intraday credit, to cover the payment. If funds are available, the Federal Reserve debits the sender bank master account and credits the receiver bank master account immediately. The receiver bank then credits the beneficiary account and sends a confirmation. Settlement is final the moment the Federal Reserve processes the transfer, and it cannot be reversed except by a new payment in the opposite direction. Fedwire operates on business days, generally from 9:00 PM Eastern Time on the previous day to 7:00 PM Eastern Time, with a cutoff for customer transfers around 6:00 PM Eastern Time. There is no maximum amount, and payments are often worth millions of dollars. Banks must manage their liquidity carefully, because a large Fedwire payment can drain a master account quickly.

Fedwire and CHIPS are both high value US payment systems, but they differ in ownership, settlement method, and risk. Fedwire is operated by the Federal Reserve and settles each payment individually in real time, in central bank money. Settlement is gross, which means each payment is settled for its full amount as soon as it is processed. This eliminates settlement risk between banks, because the receiving bank gets central bank money immediately. CHIPS, the Clearing House Interbank Payments System, is a private system operated by The Clearing House, a consortium of large banks. CHIPS settles payments on a net basis. During the day, CHIPS keeps a running record of payments between banks and offsets them against each other. At the end of the day, each bank pays or receives only its net position. CHIPS also uses a prefunded balance and a liquidity saving mechanism that releases payments when offsetting payments arrive. The key difference is timing and risk. Fedwire gives immediate final settlement for each payment, while CHIPS gives final settlement at the end of the day for the net amount. Fedwire is used for domestic high value payments and for Federal Reserve operations. CHIPS is used mainly for international US dollar payments, because many foreign banks hold dollar accounts with CHIPS participants. A bank chooses the system based on the payment type, the value, the urgency, and the cost.

CHIPS netting is the process by which the Clearing House Interbank Payments System offsets payments between banks so that only the net amount needs to be settled at the end of the day. During the operating day, banks send payment instructions to CHIPS, which records them in a central queue. CHIPS does not settle each payment immediately. Instead, it keeps a running total of what each bank owes to every other bank. If Bank A owes Bank B 100 million dollars and Bank B owes Bank A 80 million dollars, the net position is 20 million dollars from A to B. CHIPS also uses a liquidity saving mechanism. It holds payments in a queue and releases them when an offsetting payment arrives, so that the net amount is smaller and less liquidity is needed. Each participant prefunds an account at the Federal Reserve Bank of New York, and CHIPS uses that prefunded balance to settle net positions. At the end of the day, CHIPS calculates the final net position for each bank and settles it by moving funds between the prefunded accounts. If a bank has a net debit, it must have enough prefunded balance to cover it. If it does not, CHIPS can use a loss sharing arrangement. Netting reduces the amount of liquidity banks need, because they do not have to fund every payment in full. The trade off is that settlement is not immediate for each payment, and banks face intraday exposure until the final net settlement.

The ACH file format is defined by Nacha, the organisation that governs the Automated Clearing House network in the United States. An ACH file is a fixed width text file made up of records, each 94 characters long. The file starts with a File Header Record, known as record type 1, which identifies the originator, the destination, the file creation date and time, and the file identification number. Next come one or more batches. Each batch starts with a Batch Header Record, type 5, which identifies the company, the service class code, the effective entry date, and the originating bank. The batch then contains Entry Detail Records, type 6, one for each payment. Each entry record contains the transaction code, the receiving bank routing number, the receiving account number, the amount, the individual identification number, the individual name, and a discretionary data field. Some entries also have Addenda Records, type 7, which carry extra information such as remittance details. The batch ends with a Batch Control Record, type 8, which contains totals for the number of entries and the total debit and credit amounts. The file ends with a File Control Record, type 9, which contains totals for the whole file. Common Standard Entry Class codes include PPD for prearranged payments and deposits, CCD for corporate credit or debit, and WEB for internet initiated entries. The file is submitted by an Originating Depository Financial Institution to an ACH operator, which routes the entries to the receiving banks.

Same Day ACH is the faster version of the Automated Clearing House network that allows payments to settle on the same business day instead of taking one to two business days. Standard ACH transactions are processed in batches overnight, so a payment initiated on Monday may not reach the payee until Tuesday or Wednesday. Same Day ACH adds extra processing windows during the day. Files submitted by 10:30 AM Eastern Time are processed in the first window, and files submitted by 2:45 PM Eastern Time are processed in the second window. Payments in those windows are settled the same day, and the receiving bank must make the funds available to the payee by 5:00 PM local time. Same Day ACH supports both credits, such as payroll and vendor payments, and debits, such as bill collections. The per transaction limit for Same Day ACH is 1 million dollars, which was raised from 100,000 dollars in March 2022. Not every ACH transaction qualifies for Same Day processing. International transactions and certain high risk entries are excluded. Banks may charge a higher fee for Same Day ACH than for standard ACH, reflecting the faster service. Same Day ACH is useful for emergency payroll, late vendor payments, and same day bill payments where a customer needs the money to arrive today. It does not replace real time systems such as FedNow or RTP, because it still settles in batches and only on business days, but it is a major improvement over the traditional next day ACH cycle.

ACH credit and ACH debit are the two directions of the Automated Clearing House system, and they differ in who initiates the payment and who controls it. An ACH credit is a payment initiated by the payer to push money to the payee. Examples include direct deposit of salary, a vendor payment, a tax refund, or a government benefit payment. The payer instructs its bank to send money, the bank debits the payer account, and the payee bank credits the payee account. The payer controls the timing and the amount, and the payee simply receives the funds. An ACH debit is a payment initiated by the payee to pull money from the payer account. Examples include a utility bill, a loan instalment, an insurance premium, or a subscription payment. The payer gives the payee an authorisation, known as a mandate, allowing the payee to debit the account on agreed dates. The payee instructs its bank to collect the money, and the payer bank debits the payer account. The risk profile differs. With an ACH credit, the risk is that the payer sends money to the wrong account. With an ACH debit, the risk is that the payee collects an amount the payer did not authorise, or collects after the authorisation was revoked. Payers have return rights for unauthorised debits, typically within 60 days for consumer accounts. Both types use the same file format and the same settlement network, but the Standard Entry Class code and the transaction code in the file identify whether it is a credit or a debit.

An ACH return code is a two or three character code that explains why an ACH transaction was returned unpaid by the receiving bank. When a bank cannot process an ACH entry, it sends the entry back through the ACH network with a return code, and the originating bank notifies the originator. Common return codes include R01, insufficient funds, which means the payer account did not have enough money to cover a debit. R02 means the account is closed. R03 means no account was found, or the account number does not match the bank records. R04 means the account number is invalid. R05 means the entry is unauthorised, which is used when a consumer claims they did not authorise a debit. R06 means the entry was returned because the Originating Depository Financial Institution requested it. R07 means the authorisation was revoked by the customer. R08 means the payment was stopped, for example because the customer placed a stop payment order. R09 means the amount is uncollected, and R10 means the customer advises the entry is unauthorised, or the authorisation was improper. Return codes are important because they determine the next steps. An R01 return may be retried after funds are available, while an R05 or R07 return should not be retried without a new authorisation. Banks must return an entry within a defined time, generally within two banking days for most returns, and within 60 days for consumer unauthorised returns. Originators track return rates, because a high return rate can lead to fines from Nacha and loss of ACH origination privileges.

RTP, the Real Time Payments network, is the instant payment system operated by The Clearing House in the United States. It launched in November 2017 and was the first new payment system in the United States in more than 40 years. RTP allows banks to send and receive payments in real time, 24 hours a day, 7 days a week, including weekends and holidays. A payment is initiated by a customer through a bank app or online banking, and the payer bank sends an ISO 20022 message to the RTP network. The network validates the message, routes it to the payee bank, and the payee bank confirms it can accept the payment. Settlement happens immediately in central bank money, using prefunded accounts that banks hold at the Federal Reserve Bank of New York. The payee bank credits the payee account within seconds and sends a confirmation. RTP supports credit transfers, request for payment messages, and rich remittance information. The transaction limit for RTP is 1 million dollars, although individual banks may set lower limits. RTP is used for payroll, bill payments, business to business payments, and person to person transfers. It is a private system, operated by The Clearing House, which is owned by large US banks. RTP does not replace ACH, Fedwire, or checks, but it fills the gap for payments that need to arrive in seconds rather than hours or days.

RTP and FedNow are both instant payment systems in the United States, but they differ in operator, governance, and reach. RTP is operated by The Clearing House, a private consortium owned by large banks, and it launched in November 2017. FedNow is operated by the Federal Reserve, a public institution, and it launched in July 2023. Both systems settle payments in seconds, operate 24 hours a day, 7 days a week, and use ISO 20022 messages. Both have a transaction limit of 1 million dollars for RTP and 500,000 dollars for FedNow at launch, although FedNow participants can set lower limits. The key differences are in participation and settlement. RTP settlement uses prefunded accounts at the Federal Reserve Bank of New York, held by The Clearing House on behalf of participants. FedNow settlement uses each participant own master account at its Federal Reserve Bank, so settlement is directly in central bank money without an intermediary account. RTP reached a large share of US bank accounts early because many large banks joined, while FedNow was designed to reach smaller banks and credit unions that were not served by RTP. A bank can join both systems, and many large banks do, so a payment can be routed through either network depending on whether the payee bank is a participant. Interoperability between the two systems is a long term goal, but for now a payment must stay on one network from payer to payee. Customers do not choose the network directly, the bank does.

Zelle is a person to person payment service in the United States that allows customers to send money to friends, family, and small businesses using a mobile number or an email address. It is operated by Early Warning Services, which is owned by seven large US banks. Zelle is not itself a settlement system. It is a messaging and directory service that sits on top of the existing payment rails. When a customer sends money through Zelle, the instruction is routed to the payer bank and the payee bank, and the actual movement of funds happens through the RTP network or through the ACH network, depending on which banks are involved and how quickly the payment needs to arrive. If both banks are RTP participants, the money can arrive in minutes. If not, the payment may be processed through ACH and take one to three business days. Zelle uses a directory that maps a mobile number or email address to a bank account, similar to how a VPA maps to an account in UPI. The customer does not need to know the payee account number. Zelle is embedded in the mobile apps of more than 2,000 banks and credit unions, and customers can also use the standalone Zelle app. The service is free for most customers, and the typical limit is 2,500 dollars per day, although some banks allow higher limits. Zelle does not offer purchase protection, so payments are best used for transfers to people the sender trusts.

The Federal Reserve plays a central role in United States payments as operator, regulator, and provider of settlement accounts. As an operator, it runs Fedwire, the high value real time gross settlement system, and FedNow, the instant payment service launched in July 2023. It also operates the National Settlement Service, which settles transactions for private clearing houses such as The Clearing House. As a provider of settlement accounts, it holds master accounts for banks and credit unions, and all major payment systems ultimately settle in Federal Reserve money. As a regulator, the Federal Reserve supervises banks and bank holding companies, sets rules for payment system risk, and works with other regulators such as the Consumer Financial Protection Bureau on consumer protection. The Federal Reserve also sets policy on access to payment systems, including which institutions can hold a master account and which can participate directly in Fedwire and FedNow. It provides intraday credit to banks through the discount window and daylight overdraft facilities, which help banks manage liquidity during the day. The Federal Reserve also publishes research on payment trends, operates the FedACH system through its regional banks, and works with the private sector on modernisation, including the adoption of ISO 20022 messages. Its dual role as operator and central bank gives it a unique position in ensuring that US payments are safe, efficient, and accessible.

US wire transfer cutoff times determine whether a payment is processed the same day or the next business day, and they vary by bank and by system. Fedwire, the Federal Reserve high value system, generally accepts customer transfers until 6:00 PM Eastern Time on business days, with the system closing at 7:00 PM Eastern Time. A wire submitted after the cutoff is processed on the next business day. Individual banks often set earlier cutoffs, such as 4:00 PM or 5:00 PM Eastern Time, to allow time for internal processing, compliance checks, and fraud screening. International wires sent through SWIFT or CHIPS may have earlier cutoffs, often 2:00 PM or 3:00 PM Eastern Time, because the payment must be routed through correspondent banks in other time zones. Same Day ACH has cutoffs at 10:30 AM and 2:45 PM Eastern Time for the two same day windows. RTP and FedNow have no cutoff times, because they operate 24 hours a day, 7 days a week, and settle each payment in seconds. Customers who need a payment to arrive the same day should submit it well before the bank cutoff, confirm the cutoff with their bank, and allow extra time for large or international payments that need additional review. A wire submitted on a Friday after the cutoff will not be processed until Monday, unless Monday is a holiday, in which case it waits until Tuesday. Banks publish their cutoff times on their websites and in their wire transfer instructions.

US banks handle OFAC screening for domestic payments by checking every payment instruction against the sanctions lists maintained by the Office of Foreign Assets Control, known as OFAC, part of the US Department of the Treasury. Although OFAC is most associated with international payments, domestic payments must also be screened, because a domestic payment can involve a sanctioned person, a sanctioned entity, or a blocked account. When a customer initiates a wire, an ACH payment, or an instant payment, the bank payment system automatically screens the names of the sender and the receiver, and any other parties named in the payment, against the Specially Designated Nationals list, known as the SDN list, and other OFAC lists. The screening uses fuzzy matching to catch spelling variations, nicknames, and transliteration differences. If a payment matches a name on the list, it is held for manual review by the bank compliance team. The team checks whether the match is a true match or a false positive. If it is a true match, the bank must block the payment and report it to OFAC. If it is a false positive, the payment is released. Banks also screen account holders when they open an account and periodically thereafter. For instant payments such as FedNow and RTP, screening must happen in seconds, so banks use automated systems that can screen and release a payment without manual intervention in most cases. A payment that cannot be cleared automatically is rejected, because instant systems do not allow a payment to be held for hours.

FedACH and EPN are the two operators of the Automated Clearing House network in the United States, and they perform the same core function through different organisations. FedACH is operated by the Federal Reserve Banks, and EPN, the Electronic Payments Network, is operated by The Clearing House. Both receive ACH files from Originating Depository Financial Institutions, validate the files, sort the entries by receiving bank, and deliver them to the Receiving Depository Financial Institutions. Both also handle settlement, returns, and notifications of change. The main difference is ownership and governance. FedACH is a public service run by the central bank, and it serves banks of all sizes, including small community banks and credit unions. EPN is a private service run by The Clearing House, and it is used mainly by larger banks, although it is open to any bank. In practice, an ACH payment can travel through either operator, and the two operators exchange files with each other so that a payment originated through FedACH can reach a bank that uses EPN, and vice versa. This is known as interoperator exchange. The fees charged by the two operators differ slightly, and banks choose an operator based on cost, service, and their existing relationship. Both operators follow the same Nacha operating rules and the same file format, so the customer experience is identical whichever operator is used. Understanding the two operators matters for operations teams, because a file rejection or a delay may need to be traced to the specific operator that processed it.

The Four Corner Model is the standard model used to describe a SEPA payment, and it has four parties at the corners of a square. At the top left is the debtor, the customer who makes the payment. At the bottom left is the debtor payment service provider, known as the debtor PSP, which is usually the debtor bank. At the bottom right is the creditor PSP, usually the creditor bank. At the top right is the creditor, the customer who receives the payment. The payment flows in a fixed order. The debtor instructs the debtor PSP to make the payment. The debtor PSP sends the payment instruction through a clearing and settlement mechanism, known as a CSM, to the creditor PSP. The creditor PSP credits the creditor account and confirms receipt. The model is useful because it separates the customer to bank space from the interbank space. In the customer to bank space, the customer uses only the IBAN to identify the payee, and the bank handles the rest. In the interbank space, banks use both the IBAN and the BIC, the Bank Identifier Code, to route the payment. The Four Corner Model applies to SEPA Credit Transfers, SEPA Instant Credit Transfers, and SEPA Direct Debits, with the direction of the instruction reversed for direct debits. It also makes it clear who is responsible for each step, which is essential when a payment fails or a dispute arises.

A CSM, a Clearing and Settlement Mechanism, is the infrastructure that sits between payment service providers in the SEPA Four Corner Model and moves payment instructions from the debtor bank to the creditor bank. It performs two functions. Clearing means sorting, validating, and routing payment instructions, and checking that they meet the scheme rules. Settlement means moving the money between the banks, usually in central bank money through TARGET2, known as T2. EBA STEP2 is one of the main CSMs in Europe. It is operated by EBA CLEARING, an association of European banks, and it is a Pan European Automated Clearing House, known as a PE-ACH. STEP2 processes SEPA Credit Transfers and SEPA Direct Debits in batches, several times a day. Banks send their payment files to STEP2, which validates them, sorts them by receiving bank, and sends them onward. Settlement of STEP2 transactions happens through accounts held at the European Central Bank, via T2. STEP2 also supports additional optional services, known as AOS, such as the Change of Account Information service used in France. Banks can choose which CSM to use, and some large banks use more than one. Other CSMs include national clearing houses that have been adapted for SEPA. The choice of CSM affects processing times and costs, but the customer experience is the same, because all CSMs must follow the same SEPA rulebooks.

SCT, the SEPA Credit Transfer, and SCT Inst, the SEPA Instant Credit Transfer, are both SEPA credit transfer schemes, but they differ in speed, processing, and technical requirements. SCT is the standard scheme, live since 28 January 2008. It allows a customer to transfer euros to any account in the 34 SEPA countries. The maximum execution time is one business day, and in practice many SCT payments arrive the same day if submitted before the bank cutoff. SCT is processed in batches through a CSM such as EBA STEP2, and settlement happens in scheduled cycles. SCT Inst, live since November 2017, is the instant version. It must be completed within 10 seconds, 24 hours a day, 7 days a week, 365 days a year, including weekends and holidays. The payer bank must send the payment immediately, the payee bank must confirm receipt within seconds, and settlement must happen in real time through TIPS, the TARGET Instant Payment Settlement service, or another instant settlement mechanism. SCT Inst has an initial maximum amount of 15,000 euros per transaction, although the limit has been raised in later rulebook versions and banks may set their own caps. SCT uses a standard interbank message with a timeout measured in hours, while SCT Inst uses strict timeouts measured in seconds, with a maximum execution time of 20 seconds in the interbank space. If the payee bank does not respond in time, the payment is rejected and the payer is notified immediately.

SCT Inst timeout rules are strict because an instant payment must either succeed or fail quickly, so that the customer is not left waiting. The scheme sets a maximum execution time of 20 seconds in the interbank space, from the moment the payer bank sends the payment to the moment it receives a confirmation from the payee bank. The target is 10 seconds, and most payments complete in less than that. The timeout is broken into stages. The payer bank has a short time to validate the payment and send it to the CSM or to TIPS. The CSM or TIPS has a short time to route it to the payee bank. The payee bank has a short time to check the account, credit the payee, and send a positive confirmation. If any stage exceeds its timeout, the payment is treated as failed. The payer bank must then inform the payer immediately, and if the payer account was debited, the debit must be reversed promptly. There is also a timeout for the customer to bank space, so the total time from the customer instruction to the customer confirmation is also limited. Banks must monitor their SCT Inst response times continuously, because a bank that is too slow can cause payments to time out. The European Payments Council publishes the exact timeout values in the SCT Inst rulebook and the implementation guidelines, and banks test their systems against those values before they join the scheme. Timeout handling is a key part of operations, because a payment that times out in the interbank space but was credited by the payee bank must be reconciled carefully to avoid a duplicate credit.

The SEPA rulebook change cycle is the annual process by which the European Payments Council, known as the EPC, updates the SEPA scheme rulebooks. Each year, the EPC publishes new versions of the rulebooks for SCT, SCT Inst, SDD Core, and SDD B2B, along with the Customer to Bank Implementation Guidelines and the Interbank Implementation Guidelines. The new versions are usually published in November, and they take effect in November of the following year, giving banks about 12 months to implement the changes. The cycle starts with a change request process, where banks, payment service providers, and other stakeholders submit proposals to change the rulebooks. The EPC reviews the proposals, consults with the market, and decides which changes to adopt. Changes can include new message fields, new timeout values, higher amount limits, new R transaction reason codes, or clarifications to existing rules. For example, the SCT Inst maximum amount was raised in later rulebook versions from the initial 15,000 euros. The EPC also publishes a change log that explains what changed and why. Banks must update their systems, test the changes, and certify that they comply with the new rulebook before the effective date. Failure to implement a mandatory change can lead to a bank being unable to process payments with other banks that have implemented it. The annual cycle keeps SEPA aligned with new regulation, new technology, and market needs.

TARGET2, now known as T2, is the real time gross settlement system operated by the Eurosystem, the European Central Bank and the national central banks of the euro area. It settles payments in central bank money, one by one, in real time, with immediate finality. T2 replaced TARGET2 in March 2023, consolidating the previous TARGET2 and TARGET2 Securities systems onto a single platform. T2 is used for high value payments, monetary policy operations, and the settlement of other payment systems. Banks hold accounts at their national central bank, and T2 debits the payer bank account and credits the payee bank account for each payment. There is no maximum amount, and payments are often worth millions of euros. T2 operates on business days, generally from 7:00 AM to 6:00 PM Central European Time, with a cutoff for customer payments at 5:00 PM. It is also the settlement system for SEPA transactions that are cleared through a CSM such as EBA STEP2. When STEP2 nets SEPA payments between banks, the net positions are settled through T2. T2 also settles instant payments that are cleared through TIPS, although TIPS has its own settlement accounts. Banks must manage their liquidity in T2 carefully, because a large payment can drain an account. The European Central Bank provides intraday credit to banks that have eligible collateral, which helps them manage their T2 liquidity during the day.

TIPS, the TARGET Instant Payment Settlement service, is the Eurosystem service that settles instant payments in central bank money, in real time, 24 hours a day, 7 days a week, 365 days a year. It was launched in November 2018 by the European Central Bank. TIPS is used to settle SCT Inst payments, the SEPA instant credit transfer scheme. When a payer bank sends an SCT Inst payment, TIPS debits the payer bank TIPS account and credits the payee bank TIPS account immediately, once the payee bank has confirmed it can accept the payment. The money moves in central bank money, so settlement is final and risk free. Banks hold dedicated TIPS accounts, known as TIPS Dedicated Cash Accounts, which are funded from their T2 accounts. They can move liquidity between T2 and TIPS as needed, although TIPS accounts must be funded around the clock because instant payments can arrive at any time, including nights and weekends. TIPS also supports instant payments in other currencies, such as Swedish krona, through links with other central banks. The service is designed for high volume and low latency, processing thousands of payments per second with a target of less than 10 seconds per payment. TIPS is the settlement layer for SCT Inst, while the clearing and routing can be done by TIPS itself or by another CSM. Its 24 hour operation is what makes SCT Inst possible at weekends and on holidays.

T2 and TIPS are both settlement systems operated by the Eurosystem, but they serve different purposes and operate on different schedules. T2, the successor to TARGET2, is the real time gross settlement system for high value payments in euros. It settles each payment individually, in real time, in central bank money, on business days, generally from 7:00 AM to 6:00 PM Central European Time. It is used for large value interbank payments, monetary policy operations, and the settlement of net positions from clearing houses such as EBA STEP2. TIPS, the TARGET Instant Payment Settlement service, is the settlement system for instant payments. It settles SCT Inst payments in central bank money, in real time, 24 hours a day, 7 days a week, 365 days a year. It is designed for high volume, low value payments that must complete in seconds. The technical design differs too. T2 processes payments one by one through a central queue, with liquidity management tools such as intraday credit and payment prioritisation. TIPS processes payments through dedicated cash accounts that banks prefund, and it uses a simpler, faster processing model optimised for instant payments. A bank can hold accounts in both systems and move liquidity between them. In practice, a SEPA Credit Transfer that is cleared through STEP2 will settle through T2, while a SEPA Instant Credit Transfer will settle through TIPS. Both systems give final settlement in central bank money, but TIPS is the only one that operates continuously.

The European Payments Council, known as the EPC, is the organisation that manages the SEPA schemes and publishes the rulebooks that banks must follow. It was founded in 2002 by European banks, and it represents payment service providers across the 34 SEPA countries. The EPC role has three main parts. First, it develops and maintains the rulebooks for SCT, SCT Inst, SDD Core, and SDD B2B. These rulebooks define the business rules, the roles and responsibilities of each party, the timelines, and the exception handling procedures. Second, it publishes the implementation guidelines, including the Customer to Bank Implementation Guidelines and the Interbank Implementation Guidelines, which define the ISO 20022 message formats that banks must use. These are updated every November. Third, it manages the scheme adherence process, where a payment service provider applies to join a scheme, demonstrates that it meets the requirements, and is listed as an adherent. The EPC does not operate payment infrastructure itself. It does not run a clearing house or a settlement system. Its role is to set the rules and to coordinate the market. The EPC also works with regulators, including the European Commission and the European Central Bank, to ensure that SEPA schemes comply with European law, including the SEPA Regulation, EU 260 of 2012. When a new requirement arises, such as the Instant Payments Regulation, the EPC updates the rulebooks to reflect it. Banks that want to offer SEPA payments must adhere to the relevant EPC schemes.

The SEPA Regulation, Regulation EU 260 of 2012, is the European law that made SEPA mandatory and set the legal framework for euro payments in Europe. It is often called the SEPA Regulation or the SEPA End Date Regulation. The regulation set 1 February 2016 as the end date for domestic euro credit transfers and direct debits in the euro area. After that date, banks in euro area countries had to stop using national euro payment schemes and use only SEPA schemes for euro payments. The regulation requires that all euro credit transfers and direct debits in the SEPA area use the same standards, including the IBAN for account identification and ISO 20022 messages in the interbank space. It also sets rules on charges. A bank cannot charge more for a cross border SEPA payment than for a domestic SEPA payment of the same type. The regulation defines the rights and obligations of payment service providers and customers, including the information that must be provided before and after a payment. It also sets the rules for direct debit mandates, including the right of the debtor to a refund for an unauthorised collection. The regulation applies to all 34 SEPA countries, although non euro area countries have different end dates for their national schemes. The SEPA Regulation is the legal foundation that turned SEPA from a voluntary industry initiative into a binding requirement, and it is enforced by national regulators in each member state.

IBAN, the International Bank Account Number, is the standard format for identifying a bank account in SEPA and in many other countries. It was developed by the International Organization for Standardization and is defined in ISO 13616. An IBAN has a maximum of 34 characters and is made up of four parts. The first two characters are the country code, for example DE for Germany, FR for France, or GB for the United Kingdom. The next two digits are check digits, calculated using a standard algorithm, which allow a bank to detect a typing error. The next four characters are the bank identifier, which identifies the bank or branch. The remaining characters, up to 30, are the Basic Bank Account Number, known as BBAN, which identifies the individual account within that bank. The length of the IBAN varies by country. A German IBAN is 22 characters, a French IBAN is 27 characters, and a British IBAN is 22 characters. An example of a German IBAN is DE89 3704 0044 0532 0130 00, where DE is the country, 89 are the check digits, 37040044 is the bank code, and 0532013000 is the account number. IBANs are printed on bank statements and are used for all SEPA payments. Customers only need to provide the IBAN, not the BIC, in the customer to bank space, under the IBAN only rule. Banks validate the IBAN format and the check digits before processing a payment, which reduces errors.

The IBAN only rule is a SEPA requirement that a customer only needs to provide the IBAN to make a payment, and does not need to provide the BIC, the Bank Identifier Code. Before SEPA, customers often had to provide both the account number and the bank code, or the IBAN and the BIC, to make a cross border payment. This was inconvenient and error prone, because a customer might not know the BIC of the payee bank. The SEPA Regulation, EU 260 of 2012, introduced the IBAN only rule for the customer to bank space. When a customer instructs a payment through online banking or a branch, they enter only the payee IBAN and the amount. The payer bank is responsible for deriving the BIC from the IBAN, using a directory that maps IBANs to BICs. In the interbank space, banks still use both the IBAN and the BIC to route the payment through the CSM to the correct payee bank. The IBAN only rule applies to SEPA Credit Transfers and SEPA Direct Debits. It simplifies the customer experience and reduces the risk of a payment failing because the BIC was wrong or missing. Banks must maintain up to date BIC directories and must be able to resolve an IBAN to a BIC quickly. If a bank cannot derive the BIC from an IBAN, it must reject the payment and inform the customer. The rule is one of the key simplifications that made SEPA payments as easy as domestic payments.

R transactions are the exception handling transactions in SEPA, and they cover what happens when a payment cannot be processed normally. There are four types, known by the letter R. A reject is when a payment is rejected before settlement, for example because the account number is invalid, the IBAN check digits are wrong, or the payment exceeds a limit. The payment is returned to the payer bank with a reason code, and no money moves. A return is when a payment has already been settled but cannot be credited to the payee, for example because the account is closed. The payee bank returns the funds to the payer bank. A refund is when the debtor claims a refund for a direct debit, for example because the collection was unauthorised or the amount was wrong. Under SDD Core, the debtor has a right to a refund within eight weeks of the debit for an authorised collection, and within 13 months for an unauthorised collection. Under SDD B2B, there is no refund right for an authorised mandate. A recall is when the payer bank asks the payee bank to return the funds after a credit transfer has been settled, for example because the payment was made in error, was duplicated, or was fraudulent. The payee bank must check whether the funds are still available and whether the payee agrees to return them. Each R transaction has a specific reason code, a time limit, and a message format defined in the SEPA rulebooks. Banks must handle R transactions within the defined timelines, or they face penalties.

The SCT recall process is the procedure by which a payer bank asks a payee bank to return funds after a SEPA Credit Transfer has already been settled. A recall is needed when a payment was made in error, for example to the wrong IBAN, for the wrong amount, or as a duplicate, or when the payment was fraudulent. The payer, the debtor, contacts their bank and requests a recall, providing the original payment details, including the amount, the date, the IBAN, and the reason. The payer bank sends a recall message, known as a camt.056 message in ISO 20022, to the payee bank through the CSM. The payee bank must respond within a defined time, usually within 10 business days, although the exact deadline depends on the reason and the rulebook version. The payee bank checks whether the funds are still in the payee account and whether the payee agrees to return them. If the payee agrees, the payee bank sends the funds back with a positive response, known as a camt.029 message, and the payer is refunded. If the payee does not agree, or the funds have already been withdrawn, the payee bank sends a negative response, and the payer bank informs the payer that the recall failed. A recall is not a guarantee of a refund, because the payee has a right to the funds once they are credited. If the recall fails, the payer may need to pursue legal action. Banks must log all recalls and report them in their exception handling statistics.

The SEPA Direct Debit mandate flow is the process by which a debtor authorises a creditor to collect payments from the debtor account on a recurring or one off basis. First, the creditor provides a mandate form to the debtor, either on paper or electronically. The mandate contains the debtor name, the debtor IBAN, the creditor name, the creditor identifier, the mandate reference, and the type of mandate, either SDD Core or SDD B2B. The debtor signs the mandate, either physically or electronically, and returns it to the creditor. The creditor stores the mandate and sends the mandate details to the creditor bank before the first collection. The creditor bank checks the mandate and forwards the details to the debtor bank through the CSM. The debtor bank stores the mandate information and, for SDD B2B, verifies the mandate before allowing a collection. When a collection is due, the creditor sends a direct debit instruction to the creditor bank, which sends it through the CSM to the debtor bank. The debtor bank debits the debtor account on the due date and credits the creditor bank, which credits the creditor account. The debtor receives a pre notification from the creditor at least 14 days before the first collection, or a shorter period if agreed. The debtor can cancel the mandate at any time by informing the creditor or the debtor bank. Under SDD Core, the debtor has a refund right for eight weeks for an authorised collection, and 13 months for an unauthorised collection. Under SDD B2B, there is no refund right for an authorised mandate, but the debtor bank must verify the mandate before the first collection.

SDD Core and SDD B2B are the two SEPA Direct Debit schemes, and they differ in who can use them and what refund rights apply. SDD Core, live since 2 November 2009, is the standard scheme for consumers and businesses. Any debtor, whether a person or a company, can be debited under SDD Core. The debtor has strong refund rights. For an authorised collection, the debtor can request a refund within eight weeks of the debit date, without giving a reason. For an unauthorised collection, where no valid mandate exists, the debtor can request a refund within 13 months. The creditor must provide a pre notification before each collection. SDD B2B, also live since 2 November 2009, is the business to business scheme, for collections between businesses only. A consumer cannot be a debtor under SDD B2B. The key difference is that there is no refund right for an authorised mandate under SDD B2B. Once a B2B collection is made under a valid mandate, the debtor cannot claim a refund. The debtor bank must verify the mandate before the first collection and before each collection if the mandate details change. This gives the creditor greater certainty that the funds will not be returned. SDD B2B is used for business payments where the debtor wants to give the creditor certainty, such as regular supplier payments. The two schemes use different message types and different timelines, and a bank must support both if it offers direct debits to business customers.

Faster Payments is the near instant payment system of the United Kingdom, operated by Pay.UK. It allows customers to send money from one UK bank account to another in seconds, 24 hours a day, 7 days a week, including weekends and bank holidays. A customer initiates a payment through online banking, a mobile app, or telephone banking, entering the payee sort code, account number, amount, and reference. The payer bank checks the balance, debits the payer account, and sends the payment message to the Faster Payments central infrastructure. The central system validates the message, checks that the payee bank is a participant, and routes it to the payee bank. The payee bank credits the payee account and sends a confirmation back through the central system to the payer bank. The whole process normally completes in less than 15 seconds, and in most cases in under 5 seconds. Faster Payments is used for person to person transfers, bill payments, salary payments, and business payments. It is not a real time gross settlement system, because settlement between banks happens through a net settlement process at the Bank of England, several times a day. The customer sees the money arrive instantly, but the banks settle the net positions later. Faster Payments launched in 2008 and now processes billions of payments a year, making it one of the most used payment systems in the UK.

The Faster Payments limit is set by Pay.UK and by individual banks, and it varies depending on the type of payment and the channel used. The system level maximum for a single Faster Payment is 1 million pounds. This is the highest amount that the central infrastructure will accept. In practice, most banks set much lower limits for their customers. For online and mobile banking, a typical per transaction limit is between 10,000 pounds and 25,000 pounds, although some banks allow up to 100,000 pounds for business customers. For payments made in a branch or by telephone, the limit may be higher, because the bank can verify the customer identity in person. Some banks also set a daily limit, for example 25,000 pounds per day for personal customers and 100,000 pounds per day for business customers. The limit also depends on the payee. A payment to a new payee may have a lower limit for the first 24 hours, as a fraud control. A payment to a payee that has been used before may have a higher limit. Customers who need to send more than their bank limit can use CHAPS, the high value system operated by the Bank of England, which has no maximum amount. Banks review their Faster Payments limits regularly and may raise them for trusted customers. Customers should check their own bank app or website for the exact limit that applies to their account.

CHAPS, the Clearing House Automated Payment System, is the United Kingdom high value, real time gross settlement system, operated by the Bank of England. It settles each payment individually, in real time, in central bank money, with immediate finality. CHAPS is used for payments where certainty, speed, and finality matter most, and where the amount is too large for Faster Payments. Typical CHAPS payments include house purchases, where a solicitor sends the purchase price to another solicitor, large corporate payments, tax payments, and interbank settlements. There is no maximum amount for a CHAPS payment, and payments are often worth hundreds of thousands or millions of pounds. A customer instructs their bank to make a CHAPS payment, providing the payee sort code, account number, amount, and reference. The bank debits the customer account and sends the payment to the Bank of England, which debits the payer bank settlement account and credits the payee bank settlement account immediately. The payee bank then credits the payee account. CHAPS operates on business days, generally from 6:00 AM to 6:00 PM, with a cutoff for customer payments at around 5:00 PM. A CHAPS payment typically costs between 20 and 35 pounds, charged by the sending bank. Because settlement is final, a CHAPS payment cannot be reversed except by a new payment in the opposite direction. This makes it the preferred system for time critical, high value payments.

BACS, the Bankers Automated Clearing System, is the United Kingdom batch payment system for direct debits and direct credits, and it operates on a three day cycle. The cycle is known as the BACS three day cycle, and it is one of the oldest payment systems in the UK. On day one, the day of input, a bank or a business submits a payment file to BACS. The file contains the payment instructions, including the payer and payee details, the amounts, and the dates. BACS validates the file and sorts the payments by receiving bank. On day two, the day of processing, BACS sends the payment instructions to the receiving banks, which check the account details and prepare to credit or debit the accounts. No money moves on day two. On day three, the day of entry, the payments are posted to the customer accounts. Direct credits, such as salaries and pensions, are credited to the payee accounts, and direct debits, such as utility bills and loan payments, are debited from the payer accounts. Settlement between banks happens on day three through the Bank of England. BACS is used for regular, scheduled payments where speed is not critical, such as monthly salaries, regular bill payments, and government benefits. It is reliable and low cost, but it is slower than Faster Payments. A payment submitted on Monday will normally arrive on Wednesday. BACS does not operate on weekends or bank holidays, so a payment submitted on Friday will arrive on Tuesday if Monday is a bank holiday.

Pay.UK is the organisation that operates the United Kingdom retail payment systems, including Faster Payments, BACS, and the Image Clearing System for cheques. It was formed in 2018 by bringing together the operators of Faster Payments, BACS, and the Cheque and Credit Clearing Company into a single organisation. Pay.UK role is to operate the central infrastructure for these systems, set the rules that participants must follow, and manage the onboarding of new banks and payment service providers. It also manages the Payee Confirmation service, known as Confirmation of Payee, which checks that the name entered by a payer matches the name on the payee account, to reduce fraud and misdirected payments. Pay.UK is owned by its participants, mainly UK banks and building societies, and it is regulated by the Bank of England and the Payment Systems Regulator. It does not hold customer accounts and does not itself move money between banks. Settlement between banks happens through the Bank of England. Pay.UK also leads the development of the New Payments Architecture, known as NPA, which is the programme to replace the existing Faster Payments and BACS infrastructure with a single, modern, ISO 20022 based platform. The goal is to make UK retail payments faster, more resilient, and easier to innovate on, while maintaining the reliability that businesses and consumers depend on.

The New Payments Architecture, known as NPA, is the programme to modernise the United Kingdom retail payment infrastructure by replacing Faster Payments and BACS with a single, modern platform. The programme is led by Pay.UK, under the oversight of the Payment Systems Regulator and the Bank of England. The current infrastructure was built over many years, with Faster Payments launched in 2008 and BACS dating back to the 1960s. It is reliable, but it is complex, with separate systems, separate message formats, and separate settlement processes. The NPA will replace both systems with a single clearing and settlement layer based on ISO 20022 messages, the same standard used by SEPA, FedNow, and other modern payment systems. The new platform will support both instant payments and batch payments, and it will be designed to be more resilient, with better fraud controls and easier onboarding for new participants. The programme is being delivered in phases. The first phase focuses on building the core infrastructure and migrating Faster Payments volumes. Later phases will migrate BACS direct debits and direct credits. The NPA is also intended to support new services, such as request to pay and enhanced remittance information. The timeline has been extended several times, because the migration is complex and must not disrupt the billions of payments that businesses and consumers rely on each day. The Bank of England will continue to provide settlement for the new platform.

NPP, the New Payments Platform, is Australia instant payment system, launched in February 2018. It allows customers to send money between Australian bank accounts in seconds, 24 hours a day, 7 days a week, including weekends and public holidays. NPP is operated by NPP Australia Limited, a company owned by Australian banks and the Reserve Bank of Australia. The platform uses ISO 20022 messages and settles each payment in real time through the Reserve Bank of Australia Fast Settlement Service, known as FSS. A customer initiates a payment through a bank app, using a PayID, which is a simple identifier such as a mobile number, an email address, or an Australian Business Number, linked to a bank account. The payer bank sends the payment to NPP, which routes it to the payee bank, and the payee bank credits the payee account within seconds. NPP also supports Osko, the consumer facing service that most customers see, which allows payments with a description of up to 280 characters. The platform supports request to pay, recurring payments, and payments with rich data, which is useful for businesses that need to reconcile invoices. There is no system level maximum amount, although individual banks set their own limits, typically between 10,000 and 100,000 Australian dollars per transaction. NPP has transformed Australian payments, making instant payments the norm for person to person transfers and increasingly for business payments.

Pix is Brazil instant payment system, launched in November 2020 by the Central Bank of Brazil, known as Banco Central do Brasil. It allows individuals and businesses to send and receive money in seconds, 24 hours a day, 7 days a week, including weekends and holidays. Pix is free for individuals and low cost for businesses, and it has been adopted rapidly, with hundreds of millions of users. A customer initiates a Pix payment through a bank app, using a Pix key, which is a simple identifier such as a mobile number, an email address, a tax identification number, or a random key generated by the system. The payer bank sends the payment to the Central Bank of Brazil, which settles it immediately in central bank money and routes it to the payee bank. The payee bank credits the payee account within seconds. Pix supports person to person transfers, person to business payments, business to business payments, and government payments. It also supports Pix QR codes for merchant payments, Pix Cobranca for billing, and Pix Saque and Pix Troco for cash withdrawals at merchants. Pix has reduced the use of cash and card payments in Brazil, and it has increased financial inclusion by giving people without a card a way to pay digitally. The Central Bank of Brazil sets the rules, operates the central infrastructure, and monitors participants for fraud and compliance. Pix is one of the most successful instant payment systems in the world, measured by adoption and transaction volume.

FAST and PayNow are Singapore instant payment systems, operated by the Monetary Authority of Singapore through the banking industry. FAST, the Fast and Secure Transfers system, launched in 2014 and allows customers to transfer Singapore dollars between bank accounts in seconds, 24 hours a day, 7 days a week. A customer initiates a FAST payment through internet banking or a mobile app, entering the payee bank, account number, and amount. The payer bank sends the payment to the FAST central system, which routes it to the payee bank, and the payee bank credits the account immediately. FAST is used mainly for business payments and larger person to person transfers, with a typical limit of 200,000 Singapore dollars per transaction, although banks may set lower limits. PayNow, launched in 2017, is the consumer facing service built on FAST. It allows customers to send money using a mobile number, a national identification number, or a Unique Entity Number for businesses, instead of an account number. A customer registers a PayNow identifier with their bank, and anyone can send money to that identifier. PayNow is free for individuals and is widely used for splitting bills, paying friends, and paying small businesses. PayNow also supports QR code payments, known as SGQR, which combine multiple payment schemes into a single QR code. Both FAST and PayNow settle in real time, and the Monetary Authority of Singapore oversees the systems to ensure they are safe and reliable. Singapore has also linked PayNow with other countries instant payment systems, including India UPI and Thailand PromptPay, for cross border instant payments.

FPS, the Faster Payment System, is Hong Kong instant payment system, launched in September 2018 by the Hong Kong Monetary Authority. It allows customers to send Hong Kong dollars and renminbi between bank accounts and stored value facilities, such as e wallets, in seconds, 24 hours a day, 7 days a week. FPS is operated by Hong Kong Interbank Clearing Limited, on behalf of the Hong Kong Monetary Authority. A customer initiates an FPS payment through a bank app or an e wallet, using a mobile number, an email address, a Hong Kong Identity Card number, or a FPS identifier, known as a FPS ID. The payer institution sends the payment to the FPS central system, which routes it to the payee institution, and the payee institution credits the account immediately. FPS supports person to person transfers, person to merchant payments, bill payments, and government payments. It also supports QR code payments, where a merchant displays a QR code and the customer scans it to pay. FPS has a default daily limit of 10,000 Hong Kong dollars for small value transfers, although customers can raise the limit through their bank, up to 1 million Hong Kong dollars or more for larger payments. FPS is free for most personal transfers, and it has reduced the use of cash and cheques in Hong Kong. The Hong Kong Monetary Authority monitors FPS for fraud and operational risk, and it has linked FPS with other instant payment systems in the region for cross border payments.

Interac is Canada payment network, best known for Interac e Transfer, the person to person payment service, and Interac Debit, the debit card payment service. Interac e Transfer allows a customer to send money to another person in Canada using an email address or a mobile number. The sender logs into online banking, enters the recipient email or mobile number, the amount, and a security question and answer. The recipient receives a notification by email or text, logs into their own bank, answers the security question, and selects the account to deposit the money into. The money is usually available within 30 minutes, and in many cases within seconds, although it is not a real time settlement system in the same way as UPI or FedNow. The transfer is processed through the Interac network, and settlement between banks happens through the Bank of Canada. Interac e Transfer has a typical limit of 3,000 Canadian dollars per transaction and 10,000 Canadian dollars per week, although banks may set different limits. Interac also operates Interac Debit, which allows customers to pay in shops using a debit card and a PIN, and to withdraw cash from ATMs. Interac Debit transactions are authorised in real time and the customer account is debited immediately. Interac is owned by Canadian banks and credit unions, and it is regulated by the Bank of Canada. It is a central part of Canadian payments, with billions of transactions a year, and it is expanding into instant payments through the Real Time Rail, known as RTR, which is being built by Payments Canada.

Real time payment systems handle liquidity by ensuring that banks have enough funds available in their settlement accounts to cover outgoing payments at any moment, including nights, weekends, and holidays when traditional funding markets are closed. Unlike batch systems, where banks can fund a net position once a day, a real time system settles each payment immediately, so a bank must hold a balance in its settlement account around the clock. There are several ways banks manage this. First, they prefund a dedicated account at the central bank, for example a TIPS Dedicated Cash Account in Europe or a prefunded account at the Federal Reserve Bank of New York for RTP in the United States. The prefunded balance is the maximum amount the bank can send before it must top up. Second, banks monitor their liquidity in real time using dashboards that show incoming and outgoing payments, and they set alerts when the balance falls below a threshold. Third, banks use automated liquidity transfers, moving funds from a main settlement account to the instant payment account when needed, although this may not be possible outside business hours if the main system is closed. Fourth, some systems allow intraday credit or overdraft facilities, where the central bank lends funds to a bank during the day against collateral. Fifth, banks set per transaction and per customer limits to control the outflow. Liquidity management is a key operational risk for real time systems, because a bank that runs out of funds cannot send payments, and customers will see failures.

A fast payment system and an RTGS, a Real Time Gross Settlement system, are both fast, but they differ in purpose, value, and settlement method. A fast payment system, also called an instant payment system, is designed for high volume, low value retail payments, such as person to person transfers, bill payments, and small business payments. Examples include UPI in India, Faster Payments in the UK, FedNow in the US, and SCT Inst in Europe. Fast payment systems settle in seconds, operate 24 hours a day, 7 days a week, and have transaction limits, typically between 10,000 and 1 million in local currency. Settlement is often through prefunded accounts or net settlement cycles, and the customer experience is instant. An RTGS system is designed for high value, time critical payments, such as interbank transfers, large corporate payments, and government securities settlements. Examples include RTGS in India, Fedwire in the US, CHAPS in the UK, and T2 in Europe. RTGS settles each payment individually, for its full amount, in central bank money, with immediate finality. There is usually no maximum amount, and payments are often worth millions. RTGS typically operates only on business days, during defined hours, because it requires active liquidity management by banks and central bank staff. In short, a fast payment system is for everyday payments that need to be instant, while an RTGS is for large payments that need to be final and irrevocable.

Building a real time payment system requires several key design choices, and each choice affects speed, cost, risk, and adoption. First, the settlement model. A system can settle each payment individually in central bank money, as in FedNow and TIPS, or it can settle net positions at intervals, as in Faster Payments. Individual settlement is safer but needs more liquidity. Net settlement is cheaper but creates intraday risk. Second, the operating hours. A true instant system must operate 24 hours a day, 7 days a week, 365 days a year, which requires automated operations and liquidity management outside business hours. Third, the addressing scheme. A system can use account numbers, as in early IMPS, or simple identifiers such as a VPA in UPI, a PayID in Australia, or a Pix key in Brazil. Simple identifiers drive adoption because customers do not need to share account details. Fourth, the message standard. Most modern systems use ISO 20022, which supports rich data and interoperability, while older systems use proprietary formats. Fifth, the transaction limit. A low limit reduces risk but limits use cases, while a high limit increases risk and liquidity needs. Sixth, the participation model. A system can be open to all banks, including small banks through service providers, or limited to large banks. Open access drives adoption but increases onboarding complexity. Seventh, fraud and compliance controls. Instant payments cannot be recalled easily, so screening for sanctions, fraud, and errors must happen in seconds, before the payment is sent.

A real time payment system must balance speed, safety, and usability, and the design choices made at the start determine whether it succeeds. One choice is whether to build a new system or to upgrade an existing one. India built UPI as a new layer on top of IMPS, while the UK built Faster Payments as a new system alongside BACS. Another choice is the role of the central bank. In some countries, the central bank operates the system, as with FedNow in the US and Pix in Brazil. In others, a private consortium operates it, as with RTP in the US and NPP in Australia. A central bank operator gives trust and access to central bank money, while a private operator can move faster and innovate more freely. Another choice is the fee model. Many systems are free for consumers, to drive adoption, and charge businesses or banks a small fee. Another choice is interoperability. A system that can connect to other domestic systems, or to cross border instant payment links, such as PayNow to UPI, is more useful than a closed system. Another choice is the dispute and error handling process. Because instant payments settle in seconds, a payment sent to the wrong account is hard to recover, so the system needs clear rules for recalls, returns, and customer protection. Finally, the system must be designed for scale, because successful instant systems grow from millions to billions of transactions a year, and the infrastructure must handle peak volumes without failing.

A cross-border payment moves money from a sender in one country to a beneficiary in another, usually through a chain of banks because the two banks rarely hold accounts with each other directly. The process begins when the sender instructs their bank, giving the beneficiary's name, account number or IBAN, the beneficiary bank's SWIFT BIC, the amount, the currency, and the charge option.

The sending bank checks the instruction for sanctions, anti money laundering, and completeness, then debits the sender's account. If the payment currency differs from the account currency, the bank converts it at its exchange rate. The bank then sends a payment message, usually a SWIFT MT103, to the next bank in the chain, which is often a correspondent bank.

Each intermediary bank in the chain receives the message, checks it, deducts its fee if the charge option allows, and forwards it onward, moving the value through nostro accounts held with each other. The final bank, the beneficiary bank, receives the message and the covering funds, then credits the beneficiary's account and sends a confirmation back up the chain.

The whole journey can take anywhere from a few hours to several days depending on the number of intermediaries, time zones, cut off times, currency controls, and whether any bank in the chain needs to ask for more information. That is why tracking a cross-border payment means asking for its SWIFT reference, often called a UETR, so each bank can locate it in the chain.

Correspondent banking is the arrangement that lets banks move money across borders even when they have no direct relationship with each other. A bank in one country holds an account with a bank in another country, and that foreign bank acts as its correspondent, providing payment, clearing, and settlement services in that country on its behalf.

For example, a small bank in India may not have a branch in the United States, so it holds a US dollar account with a large American bank. When its customer needs to pay a supplier in the US, the Indian bank instructs its American correspondent to pay from that account. The correspondent relationship is governed by an agreement covering fees, cut off times, compliance checks, and settlement terms.

Correspondent banking is what makes the global payment network work. Without it, every bank would need a branch or a direct account in every country it sends money to, which is impossible. Instead, a payment hops through one or more correspondent banks until it reaches the beneficiary's bank.

The system has costs. Each correspondent can deduct a fee, add a day of delay, and apply its own compliance screening, which is why cross-border payments are slower and more expensive than domestic ones. In recent years many banks have reduced their correspondent networks, a trend called de-risking, which has made some payment corridors harder and more expensive to serve.

A nostro account is an account that a bank holds with a foreign bank, in the foreign bank's currency. The word nostro is Latin for ours, and it is used from the perspective of the bank that owns the account. So if an Indian bank holds a US dollar account with a bank in New York, the Indian bank calls that account its nostro account.

The purpose of a nostro account is to make payments in that foreign currency. When the Indian bank's customer pays a supplier in the United States, the Indian bank instructs its New York correspondent to debit its nostro account and pay the beneficiary. The nostro account is prefunded, meaning the Indian bank keeps a balance there so payments can go out immediately without waiting for funds to arrive.

Managing nostro accounts is a real operational task. A bank must forecast how much it will need in each currency, keep enough balance to cover outgoing payments, and avoid leaving too much idle cash earning little or no interest. Too little and payments get delayed or rejected; too much and capital is tied up unnecessarily.

The same account is called a vostro account by the bank that holds it, which is simply the other side of the same relationship. Nostro and vostro are two names for one account, seen from opposite sides.

A vostro account is an account that a foreign bank holds with your bank, in your local currency. The word vostro is Latin for yours, and it is used from the perspective of the bank that holds the account. So if an American bank holds a rupee account with an Indian bank, the Indian bank calls that account a vostro account.

The relationship is the mirror image of a nostro account. The American bank calls the same account its nostro account, because from its point of view it is our account with you. The Indian bank calls it a vostro account, because from its point of view it is your account with us. One account, two names, depending on which side of the relationship you stand on.

Vostro accounts let foreign banks make payments in your currency without opening a branch in your country. When the American bank's customer needs to pay a supplier in India, the American bank instructs the Indian bank to debit its vostro account and pay the Indian beneficiary in rupees.

For the bank holding the vostro accounts, the work includes maintaining the accounts, applying compliance checks on incoming instructions, managing liquidity, and reporting. Vostro services are also a source of fee income, and they are an important part of how banks serve foreign clients and support trade flows into their home market.

OUR, SHA, and BEN are the three standard options that decide who pays the fees charged by banks along a cross-border payment chain. They are set by the sender in the payment instruction, and they determine how much the beneficiary finally receives.

OUR means the debtor pays all charges. The sender bears every fee charged by every bank in the chain, so the beneficiary receives the full amount. This is the most expensive option for the sender, but it is often required for payments such as tuition fees, property purchases, or supplier invoices where the contract demands the full amount arrive. The sender's bank usually collects the estimated charges upfront.

SHA means the charges are shared. The sender pays the fees of their own bank, and the beneficiary pays the fees of the intermediary and beneficiary banks. This is the most common option for ordinary commercial payments, and it is the default in many systems. The beneficiary receives the amount minus the downstream charges.

BEN means the beneficiary pays all charges. Every fee in the chain is deducted from the payment, so the beneficiary receives the amount minus all charges. This is the cheapest option for the sender but can cause disputes if the beneficiary expected the full amount. Choosing the wrong option is a common cause of short payments and complaints, so the charge option should always match what the underlying invoice or contract requires.

Foreign exchange is handled at the point where the payment changes from one currency to another, and that conversion can happen at the sending bank, at an intermediary bank, or at the beneficiary bank, depending on the instruction. The sender usually chooses the currency of the payment, and the bank applies its exchange rate, which is the market rate plus a margin that covers the bank's cost and risk.

In a typical flow, a customer in India holding rupees wants to pay a supplier in euros. The sending bank debits the rupee account, converts the rupees to euros at its rate, and sends the euro payment through the SWIFT network. The beneficiary then receives euros. Alternatively, the sender can send US dollars, and the beneficiary bank converts the dollars to the local currency on arrival.

The rate applied is rarely the mid market rate seen on news sites. Banks add a spread, and the spread is wider for less common currency pairs and smaller amounts. Large corporate customers often negotiate better rates or book a forward contract to lock in a rate for a future payment, protecting themselves against adverse moves.

Timing also matters. If the conversion happens on a day when the market moves sharply, the final amount can differ from what was expected. That is why transparent FX, with the rate and the converted amount shown upfront, has become a selling point for newer payment providers, and why customers should always ask for the rate before instructing a payment.

Cross-border payments take so long because the money does not travel directly from the sender to the beneficiary. It moves through a chain of correspondent banks, and each bank in the chain must receive the payment message, check it, process it, and forward it to the next bank. Every hop adds time, especially when banks are in different time zones with different cut off times and different working days.

Compliance checks are a major source of delay. Each bank in the chain must screen the payment against sanctions lists, check for money laundering risk, and verify that the details are complete. If anything is missing or unclear, such as an incomplete beneficiary address or a vague purpose of payment, the bank will stop the payment and send a query back up the chain. Those queries and replies can take days.

Currency conversion, batch processing, and the fact that many correspondent systems still run on end of day settlement also add delay. Unlike a domestic real-time payment, a cross-border payment may wait overnight for the next processing window at an intermediary bank.

The industry is improving this. SWIFT gpi gives senders end to end tracking and faster confirmation, and newer networks settle in minutes for some corridors. But for many routes, especially those involving smaller banks or less common currencies, two to five business days remains normal, and the sender should always confirm the expected timeline before promising a delivery date.

Serial and cover are two different methods of moving a cross-border payment through the correspondent banking chain, and they differ in how the payment instruction and the funds travel. In the serial method, the payment instruction and the funds move together through the same chain of banks, one after the other. Each bank receives the message, debits the previous bank, credits the next bank, and forwards the instruction onward, so the message and the money follow the same path.

In the cover method, the two are separated. The payment instruction goes directly from the sending bank to the beneficiary bank through the SWIFT network, while the funds move separately through correspondent banks in a covering payment, usually a SWIFT MT202. The beneficiary bank receives the instruction first and knows the payment is coming, then receives the cover funds and credits the beneficiary.

The cover method is faster because the instruction does not wait for each intermediary to process it in sequence. It also gives the beneficiary bank earlier information, which helps with compliance checks and liquidity planning.

However, cover payments have historically been misused to hide the origin of funds, because the covering payment can obscure who the original sender was. That is why regulators now require cover payments to carry full originator and beneficiary information, and why banks screen them carefully. The choice between the two is a trade off between speed and transparency.

The choice between serial and cover depends on speed, cost, transparency, and the policies of the banks involved. Serial is the simpler and more transparent method. Because the instruction and the funds travel together through the same chain, every bank in the chain sees the full payment details, including the originator and the beneficiary. That makes compliance screening straightforward and reduces the risk of the payment being stopped for missing information. Serial is the safer default when the payment is going through a corridor with strict compliance requirements or when the banks involved prefer full visibility.

Cover is the better choice when speed matters. Because the instruction goes directly to the beneficiary bank, that bank can start its checks and prepare to credit the beneficiary before the funds arrive. The payment often reaches the beneficiary faster, sometimes a full day sooner than serial. Cover is common for high volume corridors between large banks that trust each other's processes.

Cost can also differ. Cover payments involve a separate covering message, which can add a fee, but the time saved may be worth more than the extra charge, especially for time sensitive commercial payments.

In practice, the choice is often made by the sending bank rather than the customer, based on its correspondent arrangements and the route. A customer who needs speed should ask their bank whether cover is available on that corridor, and a customer who needs certainty should ask whether serial is the safer option. Either way, the key is to agree the method upfront so there are no surprises in timing or fees.

A payment recall is a request by the sending bank to cancel a payment that has already been sent and to return the funds. It is used when the payment was sent by mistake, for example to the wrong beneficiary, for the wrong amount, or in duplicate, or when the underlying transaction has been cancelled.

The recall is sent as a message through the same network that carried the original payment, usually a SWIFT message asking the beneficiary bank to return the funds. The sending bank must give a clear reason, such as wrong beneficiary or duplicate payment, and provide the original payment reference so the receiving bank can identify it.

Whether a recall succeeds depends on timing and on the beneficiary. If the funds have not yet been credited to the beneficiary's account, the beneficiary bank can usually stop the payment and return the money. If the funds have already been credited and the beneficiary has withdrawn or used them, the beneficiary bank cannot simply take the money back. It must ask the beneficiary for consent to return the funds, and the beneficiary can refuse.

That is why recalls are not guaranteed. They work best when raised quickly, within hours of the original payment, and when the error is clear. A recall is also different from a fraud report: if the payment was the result of fraud, the bank will follow its fraud process alongside the recall, and may involve law enforcement. The practical lesson is to check payment details carefully before sending, because undoing a payment is far harder than getting it right the first time.

A payment return is when a payment that was sent to a beneficiary bank is sent back to the sender because it cannot be applied. Unlike a recall, which is initiated by the sender, a return is usually initiated by the beneficiary bank or an intermediary bank that cannot complete the payment.

The most common reasons for a return are incorrect beneficiary details, such as a wrong account number or a name that does not match the account, a closed or blocked account, or missing information that the beneficiary bank needs to process the credit. Compliance reasons can also cause a return: if the payment fails a sanctions or anti money laundering check at the receiving bank, it may be returned rather than credited.

When a payment is returned, the funds travel back through the chain to the sending bank, which credits the sender's account. The returned amount may be less than the original because intermediary banks may have already deducted their fees, and because a currency conversion may have happened at a different rate on the way back.

A return message should explain the reason, often with a standard return reason code, so the sender can fix the problem and resend the payment correctly. If returns happen repeatedly on the same corridor or beneficiary, it is a sign that the payment details need to be corrected at the source, such as verifying the beneficiary's account details before sending. Keeping accurate beneficiary records is the simplest way to avoid returns.

A payment is rejected when a bank in the chain decides it cannot process it, and the most common reasons fall into a few groups. The first is incorrect or incomplete details: a wrong account number, a misspelt beneficiary name, a missing IBAN, an invalid SWIFT BIC, or a missing purpose of payment. Even a small error can cause a rejection because banks cannot guess the correct details.

The second group is compliance. If the payment involves a sanctioned person, country, or entity, or if it trips an anti money laundering filter, the bank must reject it. This can happen even when the sender has done nothing wrong, for example if the beneficiary's name is similar to a sanctioned name and the bank cannot clear the match. Payments for certain goods, such as dual use items, can also be rejected if the required licences or documents are missing.

The third group is account and limit problems: the sender's account has insufficient funds, the payment exceeds a daily or per transaction limit, or the beneficiary's account is closed, dormant, or blocked.

Finally, technical issues can cause a rejection, such as a payment message that does not meet the format rules of the network or a currency that the receiving bank does not support. When a payment is rejected, the sending bank should receive a reason code and a short explanation. The fastest way to resolve it is to check that reason, correct the underlying problem, and resend. If the reason is unclear, ask the bank for the exact rejection message rather than guessing.

Nostro and vostro describe the same account from opposite sides, and they are never interchangeable, because each word belongs to one bank's books. Nostro means our account with you. When Bank A in India holds a US dollar account with Bank B in New York, Bank A calls it a nostro account. Vostro means your account with us. Bank B calls that same account a vostro account, because it is Bank A's account held on Bank B's books. The accounting is different on each side. On Bank A's books the nostro account is an asset, money Bank A owns and holds with Bank B, and a payment out of it reduces Bank A's asset. On Bank B's books the vostro account is a liability, money Bank B owes to Bank A, and the same payment reduces Bank B's liability. If you swap the words in a message, a requirement or a ledger entry, the debit and credit directions reverse and the reconciliation breaks. A business analyst must always state whose perspective applies: the ordering bank talks about its nostro, the account-holding bank talks about its vostro, and the daily nostro reconciliation agrees the two views of one balance.

Clearing and settlement are two distinct steps in completing a payment, and confusing them is one of the most common mistakes learners make. Clearing is the process of calculating who owes what. When payments are exchanged between banks, clearing sorts out the instructions, validates them, checks balances and limits, and works out the net amount each bank owes to or is owed by the others. No money moves during clearing; it is an information and calculation process.

Settlement is the step where the money actually moves. After clearing has established the amounts owed, settlement transfers funds between the banks' accounts, usually in central bank money, to discharge those obligations. Once settlement is complete, the payment is final and cannot be reversed through the normal process.

A simple example makes the difference clear. If Bank A owes Bank B 100 rupees and Bank B owes Bank A 60 rupees, clearing works out that Bank A owes Bank B a net 40 rupees. Settlement is the actual transfer of 40 rupees from Bank A's account at the central bank to Bank B's account.

The distinction matters because risk lives in the gap between the two. If clearing has happened but settlement has not, the receiving bank is exposed: it may have already credited its customer while still waiting for the money from the sending bank. That gap is the source of settlement risk, and the design of a payment system is largely about how short that gap is and how it is managed.

RTGS stands for Real Time Gross Settlement. It is a system in which each payment is settled individually, in real time, in central bank money, as soon as it is submitted and validated. There is no batching and no netting: every payment is processed on its own, and the funds move from the sending bank's account at the central bank to the receiving bank's account immediately.

The word gross is important. It means each payment is settled for its full value, not netted against other payments. If a bank sends ten payments of 10 lakh rupees each, RTGS settles ten separate transfers of 10 lakh rupees. That is different from a net settlement system, where those payments would be offset against incoming payments and only the net difference would move.

RTGS is used for high value payments because it eliminates settlement risk. Once a payment is settled in RTGS, it is final and irrevocable. The receiving bank can credit its customer with complete confidence that the money is there. In India, RTGS has a minimum of 2 lakh rupees per transaction and no maximum limit, and it is operated by the Reserve Bank of India.

The trade off is liquidity. Because each payment settles gross, banks need enough funds in their central bank account to cover each payment as it arrives. Central banks help by providing intraday liquidity, but banks must still manage their balances carefully throughout the day. RTGS is therefore the system of choice where finality and safety matter more than liquidity efficiency.

Deferred net settlement, often shortened to DNS, is a system in which payments are collected over a period of time, netted against each other, and then settled as a single net amount at the end of that period. The word deferred means settlement does not happen immediately; the word net means only the difference between what a bank owes and what it is owed actually moves.

A typical example is NEFT in India. Payments submitted during a half hourly window are collected, and at the end of the window each bank's net position is calculated. If Bank A sent 100 crore rupees and received 90 crore rupees in that window, it only needs to settle the net 10 crore rupees. That single net transfer discharges all the individual payments in the batch.

The advantage is liquidity efficiency. Banks need far less cash in their settlement accounts because most payments cancel each other out. That makes DNS cheap to run and well suited to high volume, low value retail payments.

The disadvantage is risk. Because settlement is deferred, there is a period during which the receiving bank may have credited its customer but has not yet received the funds from the sending bank. If the sending bank fails before settlement, the receiving bank is exposed. DNS systems manage this risk through limits on how much a bank can owe, collateral requirements, and frequent settlement cycles. The shorter the deferral period, the lower the risk, which is why many DNS systems have moved from daily to hourly or half hourly settlement.

Netting is the process of offsetting payments between two or more parties so that only the net amount owed is actually transferred. Instead of settling every payment separately, the parties calculate the difference between what they owe each other and settle that single net figure.

Bilateral netting is the simplest form. If Bank A owes Bank B 100 rupees and Bank B owes Bank A 60 rupees, netting reduces the two obligations to a single payment of 40 rupees from Bank A to Bank B. That is one transfer instead of two, and it needs only 40 rupees of liquidity instead of 100.

Multilateral netting extends the idea to many participants. A clearing house collects all the payments between all the banks in a system, calculates each bank's net position against the whole group, and each bank either pays or receives a single net amount. A bank that sent 500 crore rupees and received 480 crore rupees across hundreds of individual payments settles just 20 crore rupees.

Netting is powerful because it saves liquidity and reduces the number of settlements, which makes payment systems cheaper and faster to run. But it also creates interdependence: if one participant fails to pay its net obligation, the whole net settlement can be disrupted, and the clearing house needs rules for unwinding the netting or covering the shortfall. That is why netting systems are backed by membership rules, limits, and collateral arrangements that protect the other participants.

Intraday liquidity is the funds a bank has available to make payments during the course of a single business day. It is different from the bank's overall capital or its end of day balance: it is about having enough money in the right account at the right moment to settle each payment as it falls due, even if the bank expects to receive funds later in the day.

This matters most in real-time gross settlement systems such as RTGS. Because each payment settles individually and immediately, a bank must have the full amount in its central bank account at the moment the payment is submitted. A bank that expects to receive 500 crore rupees in the afternoon cannot use that money to make a 200 crore rupee payment in the morning unless it has other funds available.

Banks manage intraday liquidity in several ways. They hold balances in their central bank accounts, they use incoming payments as they arrive, they borrow in the money market, and they use intraday liquidity facilities provided by the central bank, where the bank can borrow funds during the day against collateral and repay them before the close of business.

Poor intraday liquidity management causes payments to queue or fail. A bank that runs out of funds midday will see its payments held in a queue until funds arrive, delaying its customers and potentially delaying other banks that were expecting those payments. Good liquidity management is therefore a core operational skill for any bank that participates in high value payment systems, and it is closely monitored by central banks and regulators.

Settlement risk is the risk that one party to a payment or transaction does not deliver what it owes when it is due, even though the other party has already delivered its side. In payments, it is the risk that a bank credits its customer or releases goods or securities before it has actually received the funds from the sending bank, and then the sending bank fails to pay.

A simple example shows the problem. Bank A sends a payment instruction to Bank B, and Bank B credits its customer immediately in the expectation that Bank A will settle later that day. If Bank A becomes insolvent before settlement, Bank B has paid out money it will never receive. Bank B bears the loss, and its customer keeps the funds.

Settlement risk is largest in systems where there is a long gap between the payment instruction and the final settlement, such as deferred net settlement systems that settle once a day. It is smallest in real-time gross settlement systems, where settlement happens at the same moment as the payment, so there is no gap for a failure to fall into.

Banks and system operators manage settlement risk through several tools: settling in central bank money, which carries no credit risk; shortening the time between instruction and settlement; setting limits on how much a bank can owe; requiring collateral; and using payment versus payment or delivery versus payment mechanisms that make both sides settle at the same time. Reducing settlement risk is one of the main reasons central banks have promoted RTGS for high value payments.

Herstatt risk is a specific form of settlement risk in foreign exchange transactions, named after Bankhaus Herstatt, a German bank that collapsed in 1974. The case is still taught today because it shows how time zone differences can turn a routine payment into a catastrophic loss.

On 26 June 1974, Herstatt received Deutsche Marks from its counterparties in Frankfurt during the German business day, as payment for US dollars it was supposed to deliver in New York later that day. Before the New York payment leg could be made, the German banking regulator closed the bank. Herstatt's counterparties had already paid their Deutsche Marks but never received the US dollars they were owed, and they lost the full value of those trades.

The root cause was that the two legs of a foreign exchange trade settled at different times in different time zones, leaving a window in which one side had paid and the other had not. That window is the essence of Herstatt risk: the risk that one currency leg of an FX transaction settles while the other does not.

The industry responded with payment versus payment systems, most notably CLS, which settles both currency legs simultaneously so that one cannot settle without the other. Central banks also pushed for real-time settlement and better coordination of payment hours. Herstatt risk has not disappeared entirely, because not all FX trades settle through CLS, but the 1974 collapse remains the standard warning of what happens when settlement timing is left unmanaged.

Central bank money and commercial bank money are the two forms of money used in a modern economy, and the difference between them is who owes it and how safe it is. Central bank money is money issued by the central bank, such as the Reserve Bank of India. It exists as physical cash and as balances that banks hold in accounts at the central bank. Because the central bank cannot go bankrupt in its own currency, central bank money is considered risk free: a claim on the central bank will always be honoured.

Commercial bank money is money created by commercial banks when they make loans and take deposits. When a customer sees a balance in their bank account, that balance is commercial bank money: it is a claim on that bank, not on the central bank. It is only as safe as the bank that issued it. If the bank fails, the depositor may lose money beyond what deposit insurance covers.

The distinction matters in settlement. When banks settle payments between themselves, they prefer to settle in central bank money, because that removes credit risk from the settlement itself. In an RTGS system, for example, payments are settled by moving balances between banks' accounts at the central bank. Once that transfer happens, the receiving bank is certain the money is there.

In everyday life, most of the money people use is commercial bank money, in bank accounts and digital wallets. The system works because commercial banks hold enough central bank money to settle their obligations to each other, and because the central bank stands behind the system as lender of last resort. Understanding the two forms of money is the key to understanding why settlement design matters so much.

Payment status and settlement finality are different things, and confusing them causes real operational mistakes. Payment status is what a message says about a payment: a pacs.002 can report ACCP for accepted, RJCT for rejected, or PART for partially accepted. It is information, not money movement. Settlement finality is the moment value moves finally and irrevocably between banks, usually in central bank money through an RTGS account or a clearing house settlement account. A payment can be accepted but not yet settled, for example while it waits for its value date or for liquidity. A payment can be settled but not yet credited to the beneficiary customer, because the beneficiary bank still has to post it to the customer account. The four moments to keep apart are: message sent, payment accepted, payment settled, and customer account credited. Only the last one is visible to the beneficiary customer. For a business analyst, every requirement, test case and reconciliation rule must say which moment it refers to, because the controls, the timing and the failure handling are different for each.

Settlement is the moment money actually moves between banks to back up a payment instruction, and it is separate from the message that started the payment. When you send money, the payment message travels first, often in seconds, but the value behind it is settled later through accounts that banks hold with each other or with a central bank.

In most systems, settlement works in batches or on a net basis. During the day, banks collect thousands of payment instructions and work out what each bank owes every other bank. Instead of moving money for every single payment, they net the amounts down to one smaller figure per bank pair, or per bank against the system as a whole. At a set cut-off time, the net amounts are moved between settlement accounts. This is why a payment can show as sent long before the receiving bank has actually received the funds.

High value systems such as RTGS work differently. They settle each payment individually and in real time, in central bank money, with finality. That is why they are used for large and time critical transfers. The key idea to remember is that clearing is about exchanging and agreeing the instructions, while settlement is about moving the actual money. A payment is not truly complete until settlement has happened, because until then the receiving bank is effectively trusting that the sending bank will pay.

A settlement account is the account a bank or payment institution uses to pay and receive the money that settles its payment obligations. Think of it as the bank's own current account for settling with other banks, rather than an account belonging to a customer. When a bank owes money to another bank after a day of payments, it pays from its settlement account. When it is owed money, the funds arrive into that same account.

In most countries the main settlement accounts are held at the central bank. A commercial bank keeps a balance there, and settlement happens by moving central bank money from one bank's account to another's. This is the safest form of settlement because central bank money carries no credit risk from another commercial bank. Some banks also hold settlement accounts with correspondent banks abroad, which is how cross border settlement works when there is no shared central bank.

Settlement accounts usually need to be funded in advance, which is why liquidity management matters so much in payments. If a bank does not hold enough in its settlement account at the cut-off time, its payments can be delayed or rejected, even though its customers have enough money in their own accounts. That is also why banks monitor their settlement balances intraday, forecast their payment flows, and sometimes borrow from the central bank or the money market to cover a shortfall. The settlement account is therefore the plumbing that turns a payment message into real, final money movement.

A card payment involves four main parties plus the card network in the middle. You are the cardholder, the shop is the merchant, the merchant's bank is the acquirer, and your bank is the issuer. When you tap or insert your card, the merchant's terminal sends the transaction details to the acquirer, which passes them through the card network, such as Visa or Mastercard, to your issuer.

Your issuer then checks several things in a fraction of a second. It checks that the card is valid and active, that you have enough credit or balance, and that the transaction does not look like fraud. If everything passes, it sends back an approval, and the merchant completes the sale. At this point no money has moved yet. The approval is only a promise that the issuer will pay, and a hold is placed on your available balance or credit limit.

Later, usually at the end of the day, the merchant batches all its card transactions and sends them to the acquirer for clearing. The acquirer sends them through the network to each issuer, and settlement follows: the issuer pays the acquirer through the network, the acquirer pays the merchant minus its fees, and your issuer posts the charge to your account. This is why a card purchase can appear as pending for a day or two before it becomes a final posted transaction. The whole system works because the network sets the rules and guarantees the flow between thousands of issuers and acquirers that would otherwise have to connect to each other directly.

The issuer and the acquirer sit on opposite sides of a card transaction, and confusing them is one of the most common mistakes learners make. The issuer is your bank, the bank that gave you the card. It owns the relationship with the cardholder, decides your credit limit or checks your account balance, approves or declines each transaction, and sends you the statement. When you dispute a charge, it is the issuer you call. The issuer earns most of its card income from interchange fees and, for credit cards, from interest.

The acquirer is the merchant's bank. It owns the relationship with the shop or website that accepts the card. It provides the terminal or the online payment gateway, receives the merchant's transactions, passes them to the card network, and pays the merchant after settlement. The acquirer takes on the risk that the merchant might fail to deliver goods or go out of business, which is why it underwrites merchants before signing them up. It earns its income from the merchant service charge, which is the fee the merchant pays on every card sale.

A simple way to remember it is that the issuer issues cards to people who spend, while the acquirer acquires transactions from merchants who sell. In a purchase, the money flows from the issuer, through the network, to the acquirer, and then to the merchant. In some cases one bank can be both issuer and acquirer, for example when you use your bank's card at a shop that also banks with the same bank, and then the transaction stays inside one institution. But the two roles, and the two sets of responsibilities, remain distinct.

Authorization, clearing, and settlement are the three stages of a card payment, and each one does a different job. Authorization happens at the moment you pay. The merchant asks your issuer, through the acquirer and the card network, whether the transaction can go ahead. The issuer checks the card status, the available funds or credit, and fraud signals, then replies with an approval or a decline. If approved, a hold is placed on your funds, but no money has moved yet. This is why a purchase can show as pending.

Clearing happens later, usually when the merchant batches its transactions at the end of the day. The acquirer sends the cleared transaction records through the network to the issuers. Clearing is the exchange of the transaction details and the calculation of who owes whom. It turns the individual authorizations into a set of obligations between issuers, acquirers, and the network, including the fees that apply to each transaction, such as interchange.

Settlement is the final stage, when money actually moves. The issuer pays the acquirer through the network's settlement accounts, and the acquirer pays the merchant, minus fees. Only after settlement does the merchant truly have the money, and only then does the pending charge on your account usually become a posted transaction. A useful way to think about it is that authorization is permission, clearing is the paperwork and the maths, and settlement is the money. A payment can be authorized but never cleared, for example if the merchant cancels the sale, and it can be cleared but delayed in settlement if a bank has a liquidity problem.

3D Secure is an extra authentication layer for online card payments, designed to prove that the person using the card is really the cardholder. You will know it as the extra step at checkout where your bank asks you to enter a one time passcode, approve the payment in your banking app, or confirm with a fingerprint or face ID. The name comes from the three domains involved: the merchant and acquirer domain, the issuer domain, and the card network that connects them.

When you pay online, the merchant sends the transaction to your issuer through the network, and the issuer decides whether extra authentication is needed. Under the newer version, 3D Secure 2, the issuer receives a lot of background information, such as your device, your location, your purchase history, and how the merchant normally behaves. If the transaction looks low risk, the issuer can approve it silently with no extra step, which is called a frictionless flow. If it looks unusual, for example a large amount, a new device, or a high risk merchant, the issuer challenges you to authenticate.

The main benefit is fraud reduction, because a stolen card number alone is no longer enough to complete a purchase. It also shifts liability: when a transaction is properly authenticated through 3D Secure, the liability for fraud generally moves from the merchant to the issuer. That is why merchants want it, even though it adds friction at checkout. The trade off is real, because every extra step loses some customers who abandon the purchase, so issuers and merchants constantly tune their rules to challenge only the transactions that genuinely look risky.

Tokenization is the replacement of a sensitive card number with a safe substitute, called a token, that can be used in its place without exposing the real number. The token looks like a card number and works in the payment system, but it is useless if stolen, because it can only be used in the specific context it was created for, such as one device, one merchant, or one type of transaction. The mapping between the token and the real card number is held securely in a token vault run by the card network or a token service provider.

You use tokenization every day without noticing it. When you add a card to Apple Pay or Google Pay, your real card number is not stored on the phone. Instead, a device specific token is created and stored in the phone's secure element. When you tap to pay, the phone sends the token plus a one time cryptogram, and the network translates the token back to your real card number before sending the transaction to your issuer. If someone intercepted the token, they could not use it on another device or for an online purchase.

Merchants use a different form of tokenization to reduce their risk and their compliance burden. Instead of storing your card number after your first purchase, they store a merchant specific token, so a breach of their database does not expose real card numbers. Tokenization is not the same as encryption, which scrambles data but can be reversed with a key. A token has no mathematical relationship to the original number, so it cannot be reversed without access to the vault. That is what makes it such a powerful tool for securing modern payments.

A chargeback is a forced reversal of a card payment, started by the cardholder through their issuer, which takes the money back from the merchant. It is a consumer protection mechanism built into the card networks, and it is very different from a refund, which the merchant agrees to give voluntarily. A cardholder can raise a chargeback for reasons such as goods never delivered, goods that were faulty or not as described, a duplicate charge, a subscription that continued after cancellation, or a transaction they do not recognise.

The process starts when the cardholder contacts their issuer and explains the problem. The issuer investigates, and if the claim looks valid, it raises the chargeback through the card network and debits the acquirer, which in turn debits the merchant's account. The merchant can dispute the chargeback by providing evidence, such as a delivery signature, a signed receipt, or proof that the service was used. This back and forth is called representment, and if the dispute continues, the card network arbitrates and makes a final decision.

Chargebacks are expensive for merchants, because they lose the sale, the goods, and a chargeback fee, and too many chargebacks can get a merchant fined or even lose its ability to accept cards. That is why merchants work hard to prevent them with clear descriptions, easy refunds, and good customer service. For cardholders, chargebacks are a safety net, but they should not be used as a first resort or as a way to get goods for free. Abusing the process, known as friendly fraud, is a growing problem and can lead to an account being closed.

A refund usually takes three to ten business days to appear in your account, even though the original payment felt instant. This is one of the most common questions in payments, and the answer comes from a simple principle that the team at Payomatix put well: follow the money, because the refund path has more stops than the payment path.

When you paid, the merchant only needed an authorization. Your issuer approved the transaction in seconds, placed a hold on your funds, and the merchant let you walk away with the goods. No money had actually moved at that point. A refund is different, because real money has to move backwards through the whole chain. The merchant first has to process the refund in its own system, which can take a day, especially if it waits for a daily batch. The refund then goes to the merchant's acquirer, through the card network, to your issuer, and each party processes it in its own batch cycle. Your issuer then has to match the refund to the original transaction, release the hold or reverse the posted charge, and update your available balance or credit limit.

Weekends and bank holidays add more delay, because clearing and settlement batches do not run every day, and a refund that crosses a weekend can sit in a queue until the next business day. Cross border refunds take longer still, because they pass through more banks and currency conversion. So the payment felt instant because it was only a promise, while the refund takes days because it is the actual unwinding of that promise, step by step, through every party that touched the original sale.

Interchange is the fee that the merchant's bank, the acquirer, pays to the cardholder's bank, the issuer, on every card transaction. It is the largest part of the fee a merchant pays to accept cards, and it is set by the card network, such as Visa or Mastercard, rather than negotiated between the two banks on each transaction. When you pay by card, the acquirer collects the merchant service charge from the merchant, keeps a small part for itself, passes the network's scheme fee to the network, and passes the interchange fee to the issuer.

Interchange exists because the issuer takes on costs and risks that the acquirer does not. The issuer funds the interest free period on credit cards, bears the risk that the cardholder does not pay, handles fraud losses and chargebacks, and provides customer service and statements. Interchange compensates the issuer for those costs and encourages banks to issue cards in the first place. Without it, banks would have little reason to offer card products, and the whole system would shrink.

Interchange rates are not flat. They vary by card type, transaction type, and region. A premium rewards credit card carries a higher interchange rate than a basic debit card, because the issuer has to fund the rewards, and a card present transaction in a shop carries a lower rate than an online transaction, because the fraud risk is lower. Regulators in many regions, including the European Union and India, cap interchange rates to keep merchant costs down. That is why a merchant sometimes prefers debit over credit, or asks for a minimum spend on cards: the fee it pays depends on the card you present.

A card authorisation flow starts when the cardholder presents a card, a phone, or card details to a merchant. The merchant terminal or website sends an authorisation request through its acquirer to the card scheme, which routes it to the issuer. The request carries the card number or token, the amount, the currency, the merchant details, and security data such as the CVV or 3D Secure result. The issuer checks the card status, the available balance or credit limit, fraud signals, and any spending controls. If the checks pass, the issuer approves the transaction and returns an authorisation code, and it places a hold on the funds so the cardholder cannot spend the same money twice. If the checks fail, the issuer declines the transaction with a decline code. The response travels back through the scheme and the acquirer to the merchant in seconds, and the merchant completes or cancels the sale. Authorisation is not the movement of money. It is a promise that funds are reserved and that the issuer will honour the payment when the merchant later submits it for clearing. The hold usually lasts a few days and then expires if the merchant never captures the payment. Analysts map this flow to define timeouts, retry rules, and the handling of partial approvals and reversals.

ISO 8583 is the international standard for messages exchanged between card issuers, acquirers, and schemes to authorise and clear card transactions. It defines a message format made of a message type indicator, a bitmap, and a set of data elements, each identified by a number. The message type indicator says what the message is for, such as an authorisation request, an authorisation response, a financial advice, or a reversal. The bitmap says which data elements are present. Data elements carry the actual values, such as the card number in data element 2, the amount in data element 4, the merchant type in data element 18, and the response code in data element 39. Different schemes and processors use their own versions and variants of ISO 8583, such as Visa Base I and Mastercard authorisation formats, so the same logical field can have slightly different rules in each implementation. ISO 8583 messages travel in real time during authorisation, usually in under two seconds, and in batch files during clearing. For a Business Analyst, ISO 8583 matters when writing interface specifications, mapping fields between systems, and investigating failed transactions. A wrong amount format, a missing data element, or a wrong message type can cause a decline or a clearing reject, so field level detail must be agreed with the scheme or processor before build.

DE55 is data element 55 in an ISO 8583 message, and it carries the EMV chip data from a card present transaction. When a card is inserted or tapped, the chip and the terminal exchange data and the chip generates a cryptogram, which is a unique code proving the card is genuine and the transaction details are correct. DE55 holds that cryptogram plus other chip data, such as the application identifier, the terminal verification results, the card verification results, and the transaction counter. The issuer uses DE55 to validate the cryptogram and confirm the chip was present and the transaction was not copied from a stolen card. EMV is the global standard for chip cards, named after Europay, Mastercard, and Visa, and it defines how the chip, the terminal, and the issuer work together. EMV data also supports contactless transactions, where the chip data is transmitted over near field communication, and it can include the cardholder verification method used, such as a PIN or no verification for a low value contactless payment. For analysts, DE55 is important in authorisation specifications and fraud investigations. A missing or invalid DE55 can cause a decline, and a mismatch between the chip data and the transaction details can signal a counterfeit card or a terminal fault.

A card scheme is the organisation that sets the rules for a card brand and connects issuers and acquirers so a card issued by one bank works at a merchant acquired by another bank. Visa and Mastercard are four-party schemes that license banks to issue cards and acquire merchants, and they operate the networks that route authorisation and clearing messages. RuPay is the domestic card scheme of India, operated by the National Payments Corporation of India, and it is used mainly for domestic transactions within India. American Express is a three-party scheme that mostly issues its own cards and acquires its own merchants, although it also licenses some banks to issue Amex cards. Each scheme publishes a rulebook covering authorisation, clearing, settlement, fees, dispute handling, security standards, and brand rules. Schemes also set interchange fees in four-party models and charge scheme fees to issuers and acquirers for using the network. The scheme does not hold the cardholder money. The issuer holds the cardholder account, and the acquirer settles the merchant. For a Business Analyst, the scheme matters because scheme rules drive product design, timelines, and compliance. A new card feature, a change in dispute time limits, or a new security mandate from a scheme must be implemented by issuers and acquirers by a set date, and failure can lead to fines or loss of licence.

A credit card lets the cardholder borrow money from the issuer up to an agreed credit limit, and repay it later, either in full or in instalments with interest. A debit card spends money directly from the cardholder bank account, and the payment is limited by the available balance. The difference affects risk, fees, and consumer protection. With a credit card, the issuer bears the risk that the cardholder may not repay, so it charges interest and may charge annual fees. With a debit card, the risk is lower because the money already exists in the account, but an overdraft can still occur if the bank allows it. Credit card purchases often carry stronger chargeback and purchase protection, and the cardholder has time to dispute a charge before paying the bill. Debit card purchases take money from the account immediately at authorisation, so a dispute can leave the cardholder out of pocket while the claim is investigated. Interchange fees also differ, and credit cards usually earn higher interchange, which funds rewards and cashback. For merchants, the acceptance cost and the settlement timing can differ between credit and debit. Analysts must keep the two products separate in requirements, because credit limits, interest, minimum payments, and credit reporting apply only to credit cards, while balance checks, overdraft rules, and instant debiting apply to debit cards.

A prepaid card is a card that is loaded with funds before it is used, and spending is limited to the loaded balance. The cardholder, an employer, or a government body loads money onto the card, and the card can then be used for purchases, ATM withdrawals, or online payments until the balance runs out. Prepaid cards are issued by banks or electronic money institutions, and they are often used for travel money, payroll, gift cards, expense management, and financial inclusion for people without a bank account. Unlike a debit card, a prepaid card is not linked to a bank account, and unlike a credit card, it involves no borrowing. The funds are held by the issuer in a safeguarded or pooled account, and the cardholder can usually check the balance and top up the card through an app or a website. Some prepaid cards are reloadable, while others are single load gift cards that are discarded when empty. Prepaid cards carry specific risks, including loss of funds if the card is lost and the balance cannot be recovered, and use for money laundering if loading limits are weak. Regulators therefore set loading limits, know your customer rules, and safeguarding duties. Analysts designing prepaid products must define loading methods, balance checks, expiry, refund of unused balances, and the handling of failed loads.

A virtual card is a card that exists only in digital form, with a card number, expiry date, and security code, but no physical plastic. It is issued through an app or a banking portal and is used for online purchases, in-app payments, and mobile wallet transactions. Virtual cards can be single use, with a number that works for one transaction and then expires, or multi-use, with a number that works for repeated purchases until the cardholder cancels it. They are popular for subscriptions, corporate expenses, and one-off online purchases, because the cardholder can set a spending limit, a merchant lock, or an expiry date, and can cancel the card instantly without waiting for a replacement in the post. Virtual cards are tokenised in wallets such as Apple Pay and Google Pay, so the real card number is never shared with the merchant. They run on the same scheme rails as physical cards, so authorisation, clearing, settlement, and chargebacks work in the same way. The main differences are in issuance and customer experience. There is no manufacturing or postal delay, and the card can be created in seconds. Analysts must define virtual card controls, such as single use versus multi-use, spending limits, merchant locking, and how refunds are handled when the virtual card has expired after the original purchase.

Step one, the cardholder presents the card, phone, or card details at checkout, and the merchant terminal or website captures the payment data. Step two, the merchant sends an authorisation request through its acquirer, including the card number or token, the amount, the currency, and the merchant details. Step three, the acquirer routes the request to the card scheme, which identifies the issuer and forwards the request. Step four, the issuer validates the card, checks that it is active and not reported lost or stolen, checks the available balance or credit limit, runs fraud checks, and checks any 3D Secure result. Step five, the issuer decides to approve or decline, places a hold on the approved amount, and returns an authorisation code or a decline code. Step six, the response travels back through the scheme and the acquirer to the merchant, usually within one to two seconds. Step seven, the merchant completes the sale if approved, or asks for another payment method if declined. Later, the merchant submits the approved transaction for clearing and settlement, and the hold becomes a final debit. If the merchant never captures the payment, the hold expires after a few days and the funds are released. Reversals can cancel an authorisation, for example when a customer changes their mind at the till.

An authorisation code, often called an auth code, is a short code returned by the issuer when a card transaction is approved. It is usually six characters, made of numbers or letters, and it proves that the issuer authorised that specific transaction. The merchant stores the auth code with the transaction record and includes it in the clearing file when the payment is submitted for settlement. The issuer can then match the clearing record to the original authorisation and confirm the amount and the merchant. The auth code is useful for customer service and investigations. If a cardholder queries a pending transaction, the bank can find the authorisation by its code and see the merchant, the amount, and the date. If a merchant submits a clearing record with a wrong or missing auth code, the issuer may reject it or query it, which delays settlement. Auth codes are also used in reversals and refunds. A reversal references the original auth code to release the hold, and a refund may reference it to link the refund to the original purchase. Auth codes are not secret, but they are not enough on their own to make a payment, because a clearing record also needs the card details, the amount, and the merchant data. Analysts must ensure the auth code is captured, stored, and passed through every system in the authorisation and clearing chain.

A decline code is a short code returned by the issuer, the scheme, or the acquirer when a card transaction is not approved. It explains, in coded form, why the authorisation failed. The code travels in the authorisation response, usually in data element 39 of the ISO 8583 message, and the merchant system may show a generic message to the cardholder, such as do not honour or try another card, while the detailed code is stored in the logs. Common decline codes include insufficient funds, lost or stolen card, expired card, invalid card number, suspected fraud, and do not honour, which is a general refusal without a specific reason. The code matters because it decides the next action. An insufficient funds decline may be retried after the customer adds money, while a lost card decline should never be retried and the card should be retained if it is a physical terminal. A suspected fraud decline may trigger a call to the issuer. Merchants and acquirers analyse decline codes to find patterns, such as a spike in declines from one issuer or one region, which can point to a system fault or a fraud attack. For a Business Analyst, decline codes must be mapped clearly in requirements, because the merchant experience, the retry logic, and the customer message all depend on the code, and a wrong mapping can cause repeated failed attempts or a poor customer experience.

The most common decline reason is insufficient funds, where the cardholder balance or available credit does not cover the purchase. Other frequent reasons include an expired card, an incorrect CVV or expiry date, a card reported lost or stolen, and a card that has been blocked by the issuer after suspected fraud. A do not honour decline is a general refusal where the issuer does not give a specific reason, often because of a risk rule or an account restriction. Technical declines also happen, such as a timeout, a system error at the issuer, or a malformed message, and these may succeed on retry. Fraud rules cause declines when the transaction looks unusual, for example a large purchase in a new country, many rapid attempts, or a merchant type the issuer restricts. Spending controls can decline a transaction that exceeds a daily limit, a per transaction limit, or a limit set by the cardholder in an app. A card not activated, a card not yet enabled for online use, or a card restricted to domestic use can also be declined. For merchants, understanding decline reasons helps reduce lost sales. Clear error messages, address checks, and 3D Secure handling can prevent avoidable declines, while retry logic should only retry declines that can succeed, such as a timeout, and never retry a lost or stolen card.

A card present transaction is one where the physical card and usually the cardholder are present at the point of sale, such as inserting or tapping a card at a shop terminal or using a card at an ATM. The chip or magnetic stripe is read, and the terminal may ask for a PIN. A card not present transaction is one where the card is not physically read, such as an online purchase, a phone order, a mail order, or a recurring subscription. The merchant uses the card number, expiry date, and security code typed by the customer, or a stored token. The difference matters for risk and liability. Card present transactions are lower risk because the chip cryptogram proves the card is genuine, and the liability for counterfeit fraud usually sits with the party that did not support chip technology. Card not present transactions are higher risk because the card details may have been stolen, so merchants use extra checks such as 3D Secure, address verification, and CVV checks, and the liability for fraud usually sits with the merchant unless 3D Secure shifts it to the issuer. Interchange fees are often higher for card not present transactions to reflect the higher risk. Analysts must classify transactions correctly in requirements, because the authorisation data, the fraud rules, the fee calculation, and the dispute process all depend on whether the card was present.

CVV, or Card Verification Value, and CVC, or Card Verification Code, are the three or four digit security codes printed on a card. On Visa, Mastercard, and RuPay, the code is three digits on the back of the card. On American Express, it is four digits on the front. The code is not stored on the chip or the magnetic stripe, and merchants are forbidden from storing it after authorisation. Its purpose is to prove the customer holds the physical card, which helps in card not present transactions where the chip cannot be read. When a customer enters the CVV online, the merchant sends it in the authorisation request, and the issuer compares it with the value it calculated when the card was issued. The issuer returns a result code, such as match, no match, or not processed, and decides whether to approve or decline based on that result and other risk signals. A wrong CVV usually causes a decline, and repeated wrong attempts can trigger a fraud block. The CVV is not a password and it does not prove the identity of the cardholder, only that the person entering the details has seen the card. It can be stolen if the card is photographed or the details are skimmed, so it is one layer among several, alongside 3D Secure, address checks, and device data.

Address Verification Service, or AVS, is a fraud check used mainly in card not present transactions in the United States, Canada, and the United Kingdom. The customer enters the billing address, usually the house number and postcode or ZIP code, at checkout. The merchant sends those details in the authorisation request, and the issuer compares them with the billing address it holds on file for the cardholder. The issuer returns an AVS result code showing whether the address matched fully, partially, or not at all. The merchant then decides whether to accept the transaction, based on its risk rules. A full match is low risk, a partial match may need review, and no match may lead to a decline or a manual check. AVS is useful because a fraudster who stole card details may not know the cardholder billing address. It is not a proof of identity, and it has limits. It only checks the numeric parts of the address in many implementations, it does not work in countries where issuers do not support it, and a genuine customer who moved house without updating their bank may fail the check. AVS results are also used in chargeback defence, because a merchant that checked AVS and got a match can show it took reasonable steps to verify the buyer. Analysts must define AVS rules per country and per merchant risk appetite.

3D Secure is the authentication protocol for online card payments, run under brand names such as Visa Secure and Mastercard Identity Check. Version 1.0, launched in the early 2000s, redirected the customer to the issuer website during checkout to enter a password or a one-time code. The experience was slow, broke the checkout flow on mobile, and caused many customers to abandon purchases. Version 2.0, known as 3DS2, was built for mobile and modern e-commerce. It shares far more data with the issuer, including device information, browser data, transaction history, and merchant risk signals, so the issuer can assess risk without always asking the customer to do anything. It supports biometric authentication, such as fingerprint or face recognition, and one-time codes through an app, and it works inside a merchant app without a full page redirect. 3DS2 also supports exemptions and risk based authentication, so low risk transactions can skip the challenge. The protocol is defined by EMVCo, and its use is driven by regulation such as Strong Customer Authentication in Europe. For a Business Analyst, the difference matters in checkout design, because 3DS2 needs data collection, device fingerprinting, and handling of both frictionless and challenge outcomes, while 3DS 1.0 was mainly a redirect and a password.

In 3D Secure, the frictionless flow is the path where the customer is authenticated without any extra step, and the challenge flow is the path where the customer is asked to prove their identity. In a frictionless flow, the issuer receives the transaction data and risk signals from the merchant and decides the transaction is low risk, so it approves the authentication silently and the checkout continues without interruption. The customer may not even notice that 3D Secure ran. In a challenge flow, the issuer decides the risk is higher and asks the customer to complete a step, such as entering a one-time code sent by text, approving a push notification in the banking app, or using a fingerprint or face recognition. The challenge appears in a window or inside the app, and the customer must complete it before the payment can proceed. The issuer chooses the flow based on risk, transaction value, merchant history, device data, and regulatory rules. Low value or trusted device transactions often go frictionless, while high value, new device, or unusual location transactions go to challenge. Merchants prefer frictionless flows because they reduce abandonment, but they must send good quality data to help the issuer trust the transaction. Analysts must design for both flows, including timeouts, error messages, and what happens if the customer abandons the challenge.

The liability shift in 3D Secure is the transfer of responsibility for a fraudulent card not present transaction from the merchant to the issuer, when the transaction has been authenticated through 3D Secure. Normally, if a cardholder claims they did not make an online purchase, the merchant bears the loss and the issuer raises a chargeback. If the merchant used 3D Secure and the issuer authenticated the cardholder, the liability shifts, and the issuer bears the loss instead, because the issuer verified the customer. The shift applies when the authentication succeeds and the merchant passes the authentication result in the authorisation request. If authentication fails, is not attempted, or the merchant does not use 3D Secure where required, the liability usually stays with the merchant. There are exceptions. Some transactions, such as recurring payments after the first authenticated payment, or transactions covered by an exemption, have their own liability rules, and some fraud types, such as a genuine cardholder disputing a valid purchase, are not covered by the shift. The liability shift is a key reason merchants adopt 3D Secure, despite the risk of checkout friction, because it reduces chargeback losses. For a Business Analyst, the shift must be understood when writing fraud and dispute requirements, because the evidence needed to claim the shift, such as the authentication value and the transaction identifier, must be stored with the transaction record.

Tokenisation replaces a sensitive card number with a substitute value called a token, which can be used for payments without exposing the real card number. If a token is stolen, it is of limited use, because it is tied to a specific merchant, device, or use case, and it can be cancelled without replacing the physical card. A network token is issued by the card scheme, such as Visa or Mastercard, through its token service. It is linked to the real card number, known as the funding PAN, and it carries extra data, such as a cryptogram that proves the token is genuine. Network tokens work across merchants and wallets, stay valid when the physical card is replaced, and are recognised by issuers for better approval rates. A PSP token is issued by a payment service provider for use within that provider system. It lets a merchant store a reference to a customer card and charge it again for subscriptions or one-click payments, without the merchant holding the real card number. PSP tokens usually only work with that provider and may not carry the same scheme level guarantees. Many flows use both, a network token for the scheme and issuer, and a PSP token as the merchant reference. Analysts must define token lifecycle, including creation, suspension, deletion, and renewal when a card expires or is replaced.

Apple Pay and Google Pay use tokenisation so a customer can pay with a phone or watch without sharing the real card number with the merchant. When a cardholder adds a card to Apple Pay or Google Pay, the wallet sends the card details to the card scheme token service, which creates a device specific token called a Device Primary Account Number, or DPAN. The DPAN is stored in the secure element of the phone or in the cloud, depending on the device, and the real card number, the Funding Primary Account Number, is never stored on the device and never shared with the merchant. For each transaction, the wallet generates a one-time cryptogram tied to the DPAN, the amount, and the merchant, and the merchant receives the DPAN and the cryptogram instead of the real card number. The scheme maps the DPAN back to the real card number and forwards the authorisation to the issuer, which approves it in the normal way. The cardholder authenticates with a fingerprint, face recognition, or device passcode, which satisfies strong customer authentication in many regions. If the phone is lost, the cardholder can suspend the DPAN without cancelling the physical card. Analysts must understand this flow for wallet acceptance, refunds, and disputes, because the merchant record shows the DPAN, not the real card number.

DPAN stands for Device Primary Account Number, and FPAN stands for Funding Primary Account Number. The FPAN is the real card number printed on the physical card and held by the issuer. It is the account that is debited when a payment is made. The DPAN is a token that represents the FPAN on a specific device, such as a phone or a watch, or for a specific merchant in an online tokenisation flow. The DPAN looks like a card number, with the same length and format, so it can travel through existing card systems, but it is not the real card number and it cannot be used on its own without the cryptogram and the device authentication. When a customer pays with Apple Pay, the merchant sees the DPAN, the scheme maps it to the FPAN, and the issuer authorises the payment against the real account. The DPAN is tied to one device, so the same card has a different DPAN on a phone and on a watch. If the device is lost, the DPAN can be suspended without affecting the FPAN or the physical card. If the physical card is replaced, the scheme can update the link so the DPAN keeps working. For support and disputes, teams must know which number they are looking at, because a search on the FPAN will not always find a DPAN transaction, and the merchant receipt will usually show the DPAN.

A clearing file is the batch file an acquirer sends to the card scheme after authorisation, containing the final details of card transactions so they can be settled between issuer and acquirer. Visa calls its clearing system Base II, and Mastercard calls its clearing system the Integrated Product Message, or IPM. Each file contains one record per transaction, with the card number or token, the amount, the currency, the merchant details, the authorisation code, and the transaction date. The scheme validates the records, checks them against the original authorisations, calculates interchange and scheme fees, and produces settlement reports for issuers and acquirers. Clearing usually happens once a day, though some schemes now support more frequent clearing. The amounts in the clearing file can differ from the authorisation amount, for example when a hotel adds charges, a restaurant adds a tip, or a partial capture is made. The clearing file is the basis for the cardholder statement and the merchant settlement, so errors in it cause reconciliation breaks and customer queries. A missing record means the merchant is not paid, and a duplicate record means the cardholder is charged twice. Analysts working on acquiring or issuing must understand the clearing file format, the field mappings, the cut-off times, and the reject handling, because a rejected record must be fixed and resubmitted before settlement.

Card settlement is the process by which money actually moves between the issuer and the acquirer after a card transaction has been authorised and cleared. Each day, the scheme nets the clearing records for each issuer and acquirer. It calculates how much each acquirer owes each issuer for the card purchases made that day, after deducting interchange and scheme fees, and it produces a settlement report and a settlement file. The acquirer pays the net amount to the scheme settlement account, and the scheme pays the net amount to the issuer, usually through accounts at a settlement bank or a central bank. The acquirer separately settles the merchant, crediting the merchant bank account with the sale amount minus the merchant service charge, usually one to two business days after the sale. The issuer debits the cardholder account, either immediately for a debit card or on the statement date for a credit card. Settlement is normally done on a net basis, so only the net difference moves, which reduces the number and size of payments. If a participant fails to settle, the scheme has rules for managing the shortfall, including collateral and loss sharing. For a Business Analyst, settlement requirements cover settlement timing, netting, currency conversion, reconciliation of settlement reports, and the handling of late or failed settlement.

Interchange is the fee the acquirer pays to the issuer for each card transaction, as compensation for the issuer costs of providing the card, bearing credit risk, and handling fraud. It is set by the card scheme and it is the largest part of the merchant service charge in most markets. Interchange is calculated as a percentage of the transaction amount, plus a fixed fee in some cases, and the rate depends on several factors. These include the card type, with credit cards usually higher than debit cards, the merchant category, the transaction channel, with card not present usually higher than card present, the region, and whether the card is domestic or cross-border. Premium and corporate cards carry higher interchange than standard consumer cards, because they offer more rewards and carry higher costs. Regulators cap interchange in some regions. In Europe, for example, consumer debit interchange is capped at 0.2 percent and consumer credit at 0.3 percent. The acquirer cannot negotiate the interchange rate, it must pay the scheme published rate for that transaction type. The merchant service charge is the sum of interchange, scheme fees, and the acquirer markup. For a Business Analyst, interchange matters in pricing, reporting, and product design, because a change in card mix or channel changes the cost of acceptance, and interchange must be calculated correctly in settlement reports.

A scheme fee is the fee a card scheme, such as Visa or Mastercard, charges issuers and acquirers for using its network and services. It covers the cost of running the network, routing authorisation and clearing messages, setting and enforcing rules, managing fraud and security programmes, and providing brand and marketing support. Scheme fees are charged on both sides of a transaction. The acquirer pays scheme fees for processing merchant transactions, and the issuer pays scheme fees for the cards it issues. The fees include per transaction charges, ad valorem charges based on the transaction value, and fixed charges such as annual licence fees, per card fees, and fees for specific services like tokenisation or 3D Secure. Scheme fees vary by region, card type, channel, and transaction type, and they change over time when the scheme updates its fee schedule. Unlike interchange, which the acquirer pays to the issuer, scheme fees are paid to the scheme itself. The merchant does not pay the scheme directly, but the acquirer passes the scheme fee through in the merchant service charge. For a Business Analyst, scheme fees matter in pricing and forecasting, because a scheme fee change raises the cost of acceptance even when interchange is unchanged, and acquirers must update their billing and reporting to reflect the new fees from the effective date.

An acquirer markup is the margin the acquirer adds on top of interchange and scheme fees when charging a merchant for card acceptance. The total merchant service charge is the sum of three parts, interchange paid to the issuer, scheme fees paid to the scheme, and the acquirer markup kept by the acquirer. The markup covers the acquirer costs of signing up and underwriting the merchant, providing terminals or gateway services, processing transactions, settling funds, handling chargebacks, and providing support, plus its profit. Acquirers offer different pricing models. In interchange plus pricing, the merchant sees the three parts separately and the markup is a clear fixed percentage and fixed fee. In blended pricing, the merchant pays one flat rate for all transactions and the acquirer absorbs the variation in interchange and scheme fees. In tiered pricing, transactions are grouped into qualified, mid-qualified, and non-qualified tiers with different rates. The markup can vary by merchant size, risk, volume, and channel, with larger merchants negotiating lower markups. For a Business Analyst, the markup matters in pricing requirements, merchant billing, and profitability reporting. Requirements must define how the markup is calculated, how it is shown on the merchant statement, and how it changes when the merchant moves pricing model or volume tier.

A chargeback reason code is the code the issuer uses to classify why a cardholder is disputing a transaction and why the issuer is raising a chargeback against the acquirer and the merchant. Each card scheme publishes a list of reason codes grouped by category, such as fraud, authorisation issues, processing errors, and consumer disputes. Examples include fraud with a card not present transaction, a transaction not recognised by the cardholder, a duplicate charge, an incorrect amount, goods not received, goods not as described, and a credit not processed after a refund was promised. The reason code matters because it decides what evidence the merchant must provide to defend the chargeback, and what the time limits are. A fraud chargeback needs proof that the cardholder authorised the transaction, such as a 3D Secure result or a signed receipt, while a goods not received chargeback needs proof of delivery. The acquirer passes the reason code to the merchant with the chargeback notification, and the merchant must respond with matching evidence before the deadline. If the merchant does not respond, the chargeback is accepted by default. Analysts must map reason codes in dispute systems, because the workflow, the evidence checklist, and the deadlines all depend on the code, and a wrong mapping can cause a winnable dispute to be lost.

Representment is the process by which an acquirer, on behalf of a merchant, disputes a chargeback by sending evidence back to the issuer to show the transaction was valid and the chargeback should be reversed. When a chargeback arrives, the merchant reviews the reason code and gathers evidence, such as proof of delivery, a signed receipt, a 3D Secure authentication result, a customer communication, or a refund record. The acquirer submits that evidence as a representment through the scheme dispute system within the time limit set by the scheme. The issuer reviews the evidence and either accepts the representment, which returns the funds to the merchant, or rejects it and moves the dispute to the next stage, which is pre-arbitration. Representment is the merchant main chance to win a chargeback, so the quality and completeness of the evidence matter. A clear delivery proof with a tracking number, a matching address, and a customer signature is far stronger than a vague statement that the goods were sent. Merchants with high chargeback volumes use representment automation to match evidence to reason codes and submit within deadlines. For a Business Analyst, representment requirements cover evidence collection, document upload, deadline tracking, and reporting on win rates by reason code, so merchants can see which disputes are worth fighting and which products cause the most losses.

Pre-arbitration and arbitration are the later stages of a card dispute when representment has not resolved the chargeback. After the issuer rejects a representment, it may raise a pre-arbitration, which is a formal second chargeback with new evidence or a new argument that the merchant response was insufficient. The acquirer and merchant can accept the pre-arbitration, which ends the dispute with the funds staying with the cardholder, or they can reject it and provide further evidence. If neither side accepts the other position, the dispute moves to arbitration, where the card scheme acts as the judge. Both sides submit their evidence and arguments, the scheme reviews the case against its rules, and it issues a binding decision on who bears the loss. The losing side usually pays an arbitration fee, which can be several hundred dollars, plus the disputed amount. Arbitration is therefore expensive and is used only for higher value or principle cases. Most disputes are resolved at the chargeback or representment stage. For a Business Analyst, pre-arbitration and arbitration must be modelled as distinct dispute states with their own deadlines, fees, and evidence rules, because missing a deadline or submitting the wrong evidence at this stage can turn a small loss into a larger one with added scheme fees.

The chargeback time limit is the deadline by which an issuer must raise a chargeback after the transaction date, and by which each side must respond at each stage of the dispute. The limits are set by the card scheme and they vary by reason code. In most schemes, the issuer must raise the chargeback within 120 days of the transaction date or the delivery date, with some fraud and processing error codes allowing up to 540 days in specific cases, such as a delayed delivery or a recurring transaction that continued after cancellation. The merchant then has a set number of days, often 30 to 45 days, to respond with representment evidence. Each later stage, including pre-arbitration and arbitration, has its own deadline, and missing a deadline usually means losing the dispute automatically, regardless of the evidence. Time limits exist to give certainty. A merchant should not face a chargeback years after a sale, and a cardholder should not wait indefinitely for a dispute to be resolved. The clock normally starts on the transaction date, but for goods not received it can start on the expected delivery date, and for cancelled recurring payments it can start on the date the cardholder cancelled. Analysts must build deadline tracking and alerts into dispute systems, because a single missed date can cost a merchant the full transaction value plus fees.

A retrieval request is a request from an issuer to an acquirer, through the card scheme, for the documents relating to a card transaction, usually before a chargeback is raised. The cardholder may have queried a transaction they do not recognise, and the issuer asks for the sales receipt, the invoice, or the proof of delivery to help the cardholder identify the purchase. The acquirer passes the request to the merchant, who must provide the documents within the scheme deadline, often 30 days. If the merchant provides clear documents, the cardholder may recognise the purchase and the matter ends without a chargeback. If the merchant does not respond, or the documents do not resolve the query, the issuer may raise a chargeback, and the merchant will have lost the chance to defend it early. Retrieval requests are sometimes called copy requests, because the issuer is asking for a copy of the transaction record. They are not a chargeback and no funds move at this stage, but they are a warning that a chargeback may follow. For a Business Analyst, retrieval requests need a workflow for receiving, tracking, and fulfilling the request, with storage of receipts and delivery proofs so the merchant can respond quickly. A good retrieval response rate reduces chargebacks and improves the merchant standing with the acquirer.

A card refund starts when the merchant agrees to return money to the cardholder, for example after a return or a cancelled order. The merchant sends a refund transaction through its acquirer to the scheme, referencing the original purchase. The scheme routes it to the issuer, which credits the cardholder account. The refund does not travel as an instant payment. It follows the same clearing and settlement cycle as a purchase, in reverse. The merchant refund is collected in a batch clearing file, usually at the end of the day, the scheme processes it overnight, and the issuer receives it the next business day. The issuer then needs time to post the credit to the cardholder account, and for a credit card the refund may appear on the next statement rather than as an immediate balance change. That is why refunds commonly take three to five business days, and sometimes up to ten days for cross-border refunds with currency conversion. The merchant cannot speed up the scheme cycle, although some acquirers offer faster refund products. A refund also needs the original authorisation to be matched, and if the card has expired or been replaced, the issuer must map the refund to the new card. Analysts must set customer expectations clearly, showing the refund as pending until it is posted, and must handle partial refunds and refunds after the original card is closed.

A card scheme compliance programme is the set of rules, monitoring, and enforcement actions a card scheme uses to make sure issuers, acquirers, and merchants follow its rulebook. The programme covers areas such as data security, fraud levels, chargeback ratios, transaction processing, brand standards, and the timely implementation of scheme mandates. Schemes monitor participants through reporting, audits, and transaction data. If a merchant has a high chargeback ratio, for example above 0.9 percent of transactions in the Visa dispute monitoring programme, the scheme can place the merchant in a monitoring programme, require a remediation plan, charge monthly fines, and ultimately stop the acquirer from processing for that merchant. Data security compliance is enforced through the PCI DSS standard, and schemes can fine acquirers whose merchants fail to comply. Schemes also issue mandates with deadlines, such as a new authentication rule or a new message format, and participants that miss the deadline face fines or restrictions. The programme protects the whole network, because one weak participant can create fraud and losses for everyone else. For a Business Analyst, compliance programmes matter in product and operations design, because monitoring thresholds, reporting, and remediation plans must be built into merchant management, fraud controls, and change delivery.

Credit cards are being reshaped by several trends that change how people pay and how banks earn money from cards. The first trend is the shift to digital wallets and tokenisation: a customer adds a card to a phone wallet, and the real card number is replaced by a token, so that a stolen token is useless to a fraudster and the physical card matters less. The second trend is the growth of real time and account to account payments, which compete with cards for everyday purchases, especially where instant payment rails are cheap and widely accepted. A customer who can pay a shop instantly from a bank account may not reach for a card at all, which puts pressure on card interchange income. The third trend is personalisation through data: banks use transaction data to offer tailored rewards, spending insights and instalment options at the point of sale, turning the card into a budgeting tool rather than a simple payment instrument. The fourth trend is sustainability and social expectations: customers ask about the carbon footprint of their spending and about the materials used in the card itself, and some banks now issue cards made from recycled plastic. Together, these trends push card issuers to compete on experience, safety and value rather than on the plastic alone.

A second set of trends is changing the economics and the technology behind credit cards. One is the rise of buy now, pay later services, which split a purchase into instalments at the checkout and compete directly with the revolving credit that cards traditionally offered. Many banks have responded by building their own instalment features into the card, so that a customer can convert a 600 euro purchase into four monthly payments from the card app. Another trend is the use of artificial intelligence for fraud detection and credit decisions: models score every transaction in milliseconds, learn from new fraud patterns, and block suspicious payments before they settle, while also helping banks offer credit limits that match each customer risk. A third trend is the move to virtual cards for online shopping and for corporate expenses, where a single use card number is created for one purchase and then expires, which limits the damage if the number is stolen. A fourth trend is embedded finance: a non-bank brand, such as a retailer or a travel company, offers a card inside its own app, with the bank providing the regulated infrastructure behind the scenes. The card therefore becomes invisible as a product, while the payment experience belongs to the brand the customer already trusts.

Sanctions screening is the process of checking every party and detail in a payment against lists of people, companies, countries, and vessels that governments have sanctioned. If a payment involves a sanctioned person or country, the bank must not process it, or must process it only under a specific licence. Screening happens before the payment is released, and it is one of the most important controls in a bank, because a single missed sanction can lead to fines running into billions and serious reputational damage.

The screening engine compares the payment message against sanctions lists, such as the OFAC list in the United States, the EU consolidated list, and the UN list, plus the bank's own internal lists. It checks the sender and receiver names, and sometimes addresses, account numbers, and the payment narrative. Because names can be spelled differently or transliterated from other scripts, the engine uses fuzzy matching, which catches close matches rather than only exact ones. A payment that matches is stopped for a human analyst to review.

Screening applies to far more than just the customer. A bank must screen its customers at onboarding and on an ongoing basis, screen every payment it processes, and screen related parties such as directors and beneficial owners. It also has to keep up with lists that change frequently, sometimes daily, as governments add or remove names. The challenge is that screening generates a huge number of alerts, most of which turn out to be false positives, so banks invest heavily in tuning their engines and in trained analysts who can clear alerts quickly without letting a real sanction slip through.

OFAC is the Office of Foreign Assets Control, the part of the United States Treasury that administers and enforces American sanctions. Its lists name the individuals, companies, countries, and vessels that US persons and businesses are forbidden to deal with, or may deal with only under strict conditions. The most important list is the Specially Designated Nationals list, known as the SDN list, which names people and entities linked to terrorism, drug trafficking, weapons proliferation, cybercrime, and human rights abuses, among other things.

OFAC matters far beyond the United States, which is why every payments professional needs to understand it. Most international payments are cleared in US dollars at some point, and any payment that touches the US financial system, a US bank, or a US person falls under OFAC's reach. Even a payment between two non US banks can be blocked if it is routed through a US correspondent bank. Because of that, banks around the world screen against the OFAC list as a matter of routine, and many build their entire sanctions programme around it.

Breaching OFAC sanctions is a strict liability offence in the US, which means a bank can be fined even if it did not intend to break the rules. The fines have been enormous, with some banks paying billions of dollars for processing payments for sanctioned countries over many years. That is why sanctions compliance is treated as a board level risk, why screening systems are tested constantly, and why a payment that hits an OFAC match is stopped immediately and escalated rather than released on a judgement call by one person.

AML stands for Anti-Money Laundering, and it is the set of laws, regulations, and controls that stop criminals from disguising illegally obtained money as legitimate income. Money laundering usually happens in three stages: placement, where dirty cash enters the financial system, layering, where it is moved through a maze of accounts and transactions to hide its origin, and integration, where it is spent or invested as if it were clean money. AML controls are designed to catch the activity at each of those stages.

The backbone of AML is a risk based approach. A bank assesses the money laundering risk of each customer, product, and country, then applies controls that match that risk. Low risk customers get standard checks, while high risk customers, such as politically exposed persons or businesses in high risk countries, get enhanced due diligence with deeper questions about the source of their wealth and funds. Banks also monitor transactions continuously, looking for patterns that do not fit a customer's normal behaviour, and they must file suspicious activity reports with their national financial intelligence unit when something looks wrong.

AML is not just a compliance exercise. It is a legal obligation with severe consequences, including large fines, loss of licence, and personal liability for senior managers. It is also why banks ask customers so many questions at onboarding and sometimes freeze or close accounts that cannot explain their funds. A payments professional needs to understand AML because every payment system they build or operate has to embed these controls, and because regulators expect the first line of defence, the business and operations teams, to spot and escalate suspicious activity rather than leave it to compliance alone.

KYC stands for Know Your Customer, and it is the process a bank or financial institution uses to verify who its customers really are before doing business with them, and to keep that understanding up to date. At its simplest, KYC answers three questions: who is this person or company, are they who they claim to be, and what is the risk they pose to the bank? It is the foundation of AML, because a bank cannot monitor for suspicious activity if it does not know who its customers are in the first place.

For an individual, KYC usually means collecting identity documents such as a passport or national ID, proof of address, and sometimes proof of income or source of funds. For a company, it is more complex. The bank must identify the legal entity, its directors, and its ultimate beneficial owners, meaning the real people who own or control more than a set percentage of the company, often 25 percent. This is where KYC gets difficult, because ownership can be hidden behind layers of holding companies in different countries.

KYC does not end at onboarding. Banks must refresh their KYC information periodically, and immediately if a customer's circumstances change, for example if they start transacting in a new country or their volumes jump sharply. They also screen customers against sanctions and politically exposed person lists on an ongoing basis. Customers often find KYC frustrating, because it involves paperwork and repeated questions, but from the bank's side it is a regulatory requirement and a key defence against fraud, money laundering, and terrorist financing. Poor KYC is one of the most common reasons regulators fine banks.

Transaction monitoring is the ongoing surveillance of customer transactions to spot activity that looks suspicious, unusual, or inconsistent with what the bank knows about that customer. It sits at the heart of AML, because KYC tells the bank who the customer is at onboarding, while transaction monitoring tells the bank what the customer is actually doing, day after day. If a customer who normally receives a salary and pays rent suddenly starts receiving large cash deposits from multiple countries, transaction monitoring is the control that should catch it.

The monitoring system works with rules and scenarios that generate alerts. Some rules are simple, such as a transaction above a threshold, or a rapid movement of funds in and out of an account. Others are behavioural, such as a change in the countries a customer deals with, transactions just below a reporting threshold, which is called structuring, or round amounts that do not fit the customer's business. Increasingly, banks also use machine learning models that learn each customer's normal pattern and flag deviations from it.

Every alert has to be investigated by a human analyst, who reviews the transaction, the customer's history, and any supporting information, then decides whether to close the alert, ask the customer for more information, or file a suspicious activity report with the financial intelligence unit. The volume is enormous, and most alerts turn out to be legitimate, so banks spend heavily on tuning their scenarios to reduce false positives without missing real crime. Good transaction monitoring depends on good data, because a system fed with incomplete or inaccurate payment data will either miss suspicious activity or drown analysts in noise.

Fraud detection works by combining rules, models, and human judgement to spot a transaction that does not look like it belongs to the genuine customer, and to stop it before the money is gone. The system scores every transaction in real time, usually in milliseconds, and decides whether to approve it, challenge it with extra authentication, or decline it outright. That scoring is based on hundreds of signals that are checked in the background.

The signals fall into several groups. Device and behavioural signals include whether the payment comes from a recognised phone or computer, the location, the time of day, and how the user types or moves the mouse. Transaction signals include the amount, the merchant, the country, and whether the purchase fits the customer's history. Velocity signals look at how many transactions have happened in a short period, because fraudsters often test a stolen card with small purchases and then go for a large one. Network signals look across many customers at once, so if the same device or address has been linked to fraud before, a new transaction from it is treated with suspicion.

Most modern systems use machine learning models trained on millions of past transactions, including confirmed fraud cases, so they can recognise patterns that a fixed set of rules would miss. But models alone are not enough. A fraud team reviews the highest risk cases, talks to customers to confirm whether a transaction was theirs, and feeds the outcome back into the model so it keeps learning. The hardest part is the balance between catching fraud and not blocking genuine customers. Every false decline is a lost sale and an annoyed customer, so the goal is not zero fraud, which is impossible, but the best trade off between fraud losses and customer experience.

PSD2 is the Second Payment Services Directive, a European Union law that reshaped payments across Europe from 2018 onwards. Its two big ideas were opening up banking through APIs, and making online payments more secure. It matters to learners outside Europe too, because its model of open banking and strong authentication has been copied by regulators around the world.

The first idea is open banking. PSD2 forced banks to let licensed third parties access customer account data and initiate payments, with the customer's consent, through secure APIs. That created two new types of provider: account information service providers, which can show a customer all their accounts in one app, and payment initiation service providers, which can start a payment directly from a bank account without a card. A customer no longer needs to use only their own bank's app to see or move their money.

The second idea is Strong Customer Authentication, or SCA. For most electronic payments, PSD2 requires at least two of three factors: something you know, such as a password or PIN, something you have, such as your phone, and something you are, such as a fingerprint. This is why European online checkouts now routinely ask for an extra confirmation in a banking app. PSD2 also capped interchange fees, banned surcharges on most consumer card payments, and made banks liable for unauthorised transactions unless they could prove the customer acted fraudulently. Its successor, PSD3, is now being developed to close gaps and extend the rules to new payment types.

A false positive in screening is an alert that looks like a match against a sanctions or watch list, but turns out to be harmless once a human investigates it. It is the single biggest operational headache in sanctions compliance, because screening systems generate far more false positives than true hits, and every one of them has to be reviewed before the payment can be released.

False positives happen for many reasons. Names are the most common cause. A customer called Mohammed Khan will match thousands of entries on sanctions lists that contain similar names, and transliteration makes it worse, because the same name in Arabic or Chinese can be spelled many different ways in English. Place names cause the same problem: a payment mentioning Georgia could mean the country, which is fine, or the US state, or it could be part of a longer word. Short names, common words, and partial matches all add to the noise, and fuzzy matching, which is needed to catch deliberate misspellings, makes the problem bigger by design.

The cost of false positives is real. They delay payments, frustrate customers, and consume huge amounts of analyst time. A large bank can receive hundreds of thousands of screening alerts a day, and over 95 percent of them may be false positives. That is why banks invest in tuning their matching rules, adding extra data such as date of birth or address to distinguish people with the same name, and using machine learning to prioritise the alerts most likely to be real. The danger is tuning too aggressively: if you suppress too many alerts to save time, you risk missing a genuine sanction, which is a far worse outcome than a delayed payment.

When a payment hits a sanction, it is stopped immediately and nothing is allowed to move until a specialist has reviewed it. The payment is held in a queue, the customer is not told the detailed reason at this stage, and a sanctions analyst investigates whether the match is genuine or a false positive. This is not a step a bank can skip or rush, because releasing a payment to a sanctioned party is a criminal offence in most jurisdictions.

If the analyst confirms it is a false positive, for example the name matches a sanctioned person but the date of birth, address, or other details prove it is a different person, the alert is cleared with a documented reason and the payment is released. The clearance is recorded so that the same customer does not get stopped for the same reason every time, although the payment may still be screened again on future transactions.

If the match is genuine, the outcome depends on the type of sanction. In most cases the payment is rejected and returned to the sender, with a short explanation that it cannot be processed. In more serious cases, particularly under US OFAC rules, the funds must be blocked or frozen, which means the bank holds the money and reports it to the regulator, and the customer cannot get it back without a licence. The bank must also file a report with its regulator and, in many countries, with its financial intelligence unit. A confirmed sanctions hit can also trigger a review of the customer relationship, and the bank may decide to exit the customer entirely if the risk is too high.

AML and fraud are related but they are not the same thing, and confusing them is a common mistake. Fraud is a crime against a victim, where someone is tricked or their account is misused to steal money. Examples include a stolen card used for purchases, a phishing email that tricks a customer into sending money to a criminal, or an employee who diverts company funds. The victim loses money, and the fraudster gains it directly. Fraud prevention is therefore about protecting the customer and the bank from loss.

AML, or anti-money laundering, is about what happens to the money after a crime has already been committed. It deals with criminals who already have illegal funds, from drug trafficking, corruption, tax evasion, or fraud itself, and who need to disguise those funds as legitimate so they can spend them without being caught. Money laundering is a crime against the financial system, not against a single victim, and its victims are society as a whole, because it allows criminal enterprises to operate and grow.

The controls are different too. Fraud controls work in real time, scoring each transaction and blocking it in milliseconds if it looks wrong. AML controls work over a longer horizon, monitoring patterns across weeks or months and filing reports when activity looks suspicious. The teams are often separate, the regulations are separate, and the reporting goes to different places: fraud losses are reported internally and to the police, while suspicious activity is reported to a financial intelligence unit. A single case can involve both, for example when the proceeds of a fraud are laundered through a bank account, which is why the two teams need to share information even though their jobs are distinct.

A payment hub is a central platform inside a bank that receives payment instructions from all the bank's channels and systems, and routes each one to the right clearing system or payment rail. Before hubs existed, each product or channel often had its own connection to each payment system, so an online banking payment, a branch payment, and a corporate bulk file might each travel through different pipes with different controls. That was expensive to maintain, hard to change, and risky, because a control applied in one pipe might be missing in another.

A hub replaces that tangle with a single layer. It takes in payments from every source, validates and enriches them, applies the bank's common controls such as sanctions screening, fraud checks, and limit checks, and then decides where each payment should go. A high value urgent payment might go to RTGS, a regular domestic payment to the local clearing system, and an international payment to SWIFT. The hub also handles the different message formats, translating the bank's internal format into ISO 20022 or the local format the clearing system expects.

For a bank, the benefit is consistency and control. A new regulation or a new payment rail can be added once, in the hub, rather than in a dozen separate systems. For a business analyst, the hub is where much of the interesting work happens, because it is where payment flows are designed, exception handling is built, and the rules that decide routing, cut-offs, and repair are written. Modern hubs are increasingly built as cloud native, API driven platforms that can process payments in real time and give customers immediate status updates, rather than the batch based systems of the past.

API banking is the delivery of banking services through application programming interfaces, so that other software can call on a bank's capabilities directly instead of going through a branch, a website, or a file upload. An API is a standard way for two systems to talk to each other, and in banking it means a company can check a balance, make a payment, or download a statement by sending a request to the bank's system and receiving a structured response back in seconds.

For corporate customers, API banking has changed how treasury works. Instead of uploading a payment file at the end of the day and waiting for a confirmation file the next morning, a company can trigger a payment from its own ERP system the moment an invoice is approved, and get a real time confirmation with the payment status. It can also pull intraday balances across all its accounts to manage liquidity, or check whether a supplier's account details are valid before paying them. This turns banking from a daily batch process into something that happens inside the customer's own workflow.

For banks, API banking is both an opportunity and a challenge. It lets them reach new customers through partners, such as a fintech that offers accounts inside its own app using the bank's licence and infrastructure. But it also means banks must manage security, authentication, and access control very carefully, because an API is a door into the bank that is always open. That is why API banking uses strong authentication, tokens that expire, and strict limits on what each partner can do. Regulators in many countries now expect banks to offer APIs, and for a payments BA, understanding how APIs work, what data they carry, and how errors are handled is now a core skill.

Open Banking is the practice of banks sharing customer financial data and payment capabilities with licensed third parties, with the customer's explicit consent, through secure APIs. Instead of your financial life being locked inside one bank's app, you can let an approved app see your accounts across several banks, or start a payment directly from your bank account without using a card. The idea is that your data belongs to you, and you should be able to share it with whoever can give you a better service.

The most visible result is account aggregation, where one app shows all your bank balances and transactions in one place, and helps you budget or find a better deal. The more powerful result is payment initiation, where you can pay a merchant or a friend directly from your bank account, bypassing the card networks entirely. This is usually cheaper for the merchant than accepting a card, and it settles faster. Open Banking has also enabled new lending models, because a lender can see a customer's real income and spending with their permission, rather than relying only on a credit score.

Open Banking started as a regulatory requirement in Europe under PSD2 and in the UK under the Competition and Markets Authority, and it has since spread to countries including Australia, Brazil, India, and parts of the Middle East, each with its own rules. The challenges are real: banks must build and maintain secure APIs, customers must understand what they are consenting to, and liability must be clear when something goes wrong. But the direction is clear, and Open Finance, which extends the same idea to investments, insurance, and pensions, is already the next step.

A payments business analyst needs a blend of domain knowledge, documentation skill, data ability, and people skill, and employers look for evidence of all four. The foundation is domain knowledge. You need to understand how payments actually work: the main rails such as SWIFT, SEPA, Faster Payments, and local clearing systems, the message standards, especially ISO 20022 and the older MT messages, and the lifecycle of a payment from initiation through clearing to settlement. You should also understand cards, sanctions screening, AML, and the key regulations in your market, because almost every payments project touches compliance.

The second skill is documentation. A BA writes business requirements documents, functional requirements, user stories, and acceptance criteria that developers can build from and testers can test against. In payments, this means being precise about message fields, cut-off times, error codes, and exception handling, because a small ambiguity can mean a payment goes to the wrong place or fails silently.

The third skill is data and analysis. You will use SQL to investigate failed payments, reconcile data, and validate test results, and you will use spreadsheets or a BI tool to analyse volumes and spot trends. You need to be able to query a database and make sense of what you find.

Finally, you need stakeholder management and testing skill. You will work with operations, compliance, technology, and external vendors, running workshops, managing conflicting priorities, and explaining technical issues in plain language. You will also support system integration testing and user acceptance testing, writing test cases, managing defects, and proving the system does what the business asked for. The BAs who succeed combine all of this with curiosity and attention to detail, because in payments, the detail is the job.

The future of payments is being shaped by three forces already in motion: instant payments becoming the default, central banks issuing digital currencies, and private stablecoins trying to do the same job for cross border payments. Together, they point to a world where money moves in seconds, at any hour, with far fewer intermediaries than today.

Central bank digital currencies, or CBDCs, are digital versions of a country's own currency, issued by its central bank. Unlike the money in your bank account, which is a claim on a commercial bank, a CBDC is a direct claim on the central bank, just like a banknote. Most CBDC projects, such as China's e-CNY and India's e-rupee, are in pilot or limited rollout, and central banks are still working out whether CBDCs should be used mainly for wholesale settlement between banks, or also for retail payments by the public. Their promise is faster settlement, lower costs, and better access to digital money, but they also raise hard questions about privacy and the role of commercial banks.

Stablecoins are privately issued digital tokens designed to hold a stable value, usually by being backed one to one by a reserve of fiat currency or government bonds. The largest ones, such as USDT and USDC, already move huge volumes each year, mostly for crypto trading and cross border transfers. Their appeal is that they settle in minutes, at any time, without correspondent banks. The risk is that the reserves behind them may not be as solid as claimed, and regulators are now bringing them under rules similar to those for banks. The most likely future is a mix: instant systems domestically, CBDCs for settlement between central banks, and regulated stablecoins for cross border commerce, all on common standards such as ISO 20022.

A payment hub is a centralized platform that processes all of a bank's payments, across channels, currencies, and payment types, through a single system. Its architecture typically has several layers. At the front, channels such as online banking, mobile apps, branches, and corporate host-to-host connections capture payment instructions. An orchestration layer validates, enriches, and routes each payment, applying business rules such as cut-off times, limits, and fraud checks. A processing layer executes the payment: it transforms the message into the format required by the clearing system, applies sanctions screening and compliance checks, and manages the payment lifecycle from initiation to settlement. A connectivity layer links the hub to clearing and settlement systems such as SWIFT, SEPA, Faster Payments, and RTGS, and to internal systems such as core banking and general ledger. Supporting services include reference data, limits, fees, and reporting. The benefit of a hub is consolidation: instead of maintaining separate silos for each payment type, the bank has one platform, one set of controls, and one view of all payments. This reduces cost, improves straight through processing rates, and makes it easier to add new payment types. For a BA, the hub is the system you will most often write requirements for.

A payment hub is usually described in layers, each with a distinct responsibility. The channel layer receives payment instructions from customers through online banking, mobile apps, branches, ATMs, and corporate file uploads. The orchestration layer is the brain: it validates the instruction, checks limits and account balances, enriches it with reference data, and decides the route, for example whether a euro payment should go via SEPA Instant or standard SEPA. The business services layer applies rules such as fees, charges, cut-off times, and value dating. The compliance layer runs sanctions screening, fraud checks, and AML transaction monitoring, and can stop or hold a payment. The transformation layer converts the payment into the message format required by the destination, such as ISO 20022 pacs.008 for a cross-border payment or a local clearing format. The connectivity layer transmits the message to the clearing system and receives acknowledgements and status updates. Finally, the settlement and accounting layer posts entries to the general ledger, reconciles nostro accounts, and generates reporting. Underpinning all of this are shared services: reference data, workflow for exceptions, and audit logging. Understanding the layers matters because a requirement usually belongs to one layer, and a change in one layer, such as a new screening rule, can affect others, such as exception handling.

A payment engine is the core processing component inside a payment hub that executes payments once they have been validated and routed. Think of it as the factory floor: it takes an approved payment instruction and drives it through the steps needed to get the money to its destination. Its responsibilities include message transformation, where the internal payment format is converted into the clearing-specific format; sequencing, where the engine applies the right order of operations such as screening, liquidity checks, and settlement; state management, where it tracks the payment through its lifecycle, from received to validated, released, settled, or rejected; and exception handling, where payments that fail a check are routed to an operations queue. The engine also manages idempotency, so a payment is never processed twice, and it handles retries and timeouts when a clearing system is slow. Modern payment engines are built for high throughput and low latency, processing thousands of transactions per second, and they are often event driven, publishing status updates that other systems consume. For a BA, the payment engine is where detailed requirements live: state machines, error codes, retry rules, and cut-off logic. A well-written functional specification for an engine reads like a precise set of rules for every state a payment can be in and every transition between them.

Message transformation and mapping is the process of converting a payment message from one format to another as it moves between systems. A payment typically starts in a channel format, is converted to the hub's internal canonical format, and is then converted again into the format required by the clearing system, for example ISO 20022 pacs.008 for SWIFT, or a local format for a domestic clearing. Mapping defines which fields go where: the debtor name in the internal format maps to the Dbtr/Nm element in pacs.008, the amount maps to the InstdAmt element, and so on. Transformation also handles differences in structure, data types, and code values, for example converting a proprietary charge code into the ISO charge bearer code, or converting a date format. It must also handle data loss: if the source format has a field the target does not support, the information must be preserved in a related field or logged, because regulators require end-to-end traceability of payment data. Transformation is usually implemented with mapping tools or XSLT, and it is tested with sample messages covering every payment type and edge case. For a BA, mapping documents are a core deliverable: a field-by-field spreadsheet showing source field, target field, transformation rule, and mandatory or optional status, validated with business and technical stakeholders.

A canonical data model is a single, standard representation of payment data used inside a bank's systems, so that every application speaks the same language. Instead of each system using its own format, all payment data is converted into the canonical model when it enters the hub and converted out of it when it leaves. The model defines the entities, such as payment, party, account, and instruction, and the attributes of each, such as amount, currency, value date, and charge bearer. The most common canonical model in payments is based on ISO 20022, which provides a standard dictionary of payment concepts. The benefit is consistency: validation, screening, enrichment, and reporting all work against one model, so a rule written once applies to every payment type. It also simplifies integration: a new channel or clearing system only needs to map to the canonical model, not to every other system. The cost is the effort of designing the model and maintaining it as standards evolve. For a BA, the canonical model is the foundation of requirements: when you write a functional specification, you describe behavior in terms of canonical fields, and when you write mapping documents, you map source and target formats to and from the canonical model. Getting the model right early saves enormous rework later.

An Enterprise Service Bus, or ESB, is middleware that connects the many systems involved in payments so they can exchange messages reliably. In a bank, payments touch core banking, the payment hub, sanctions screening, fraud systems, the general ledger, customer channels, and external clearing systems. Without an ESB, each pair of systems would need a direct point-to-point connection, creating a tangled web that is hard to maintain. The ESB sits in the middle: a system sends a message to the bus, and the bus routes it to the right destination, transforming the format if needed. It also handles reliability features such as guaranteed delivery, retries, message queuing, and error handling, so a payment is not lost if a system is temporarily unavailable. In payments, the ESB carries messages such as payment instructions, status updates, and acknowledgements, and it often enforces standards such as ISO 20022. Modern architectures are moving from heavyweight ESBs toward lighter API gateways and event streaming platforms such as Kafka, but the underlying idea is the same: decouple systems so each can change independently. For a BA, the ESB matters because integration requirements are written against it: message contracts, service level agreements, error handling, and retry behavior are all ESB concerns.

The Straight Through Processing, or STP, rate is the percentage of payments that are processed end to end without any manual intervention. It is one of the most important operational metrics in payments. The formula is simple: divide the number of payments that flowed from initiation to settlement with no human touch by the total number of payments, and multiply by 100. A high STP rate, typically above 95 percent for standard payments, means the bank's automation is working well and costs are low. A low STP rate means many payments are falling into exception queues, which costs money, delays settlement, and frustrates customers. STP is measured by payment type, channel, and currency, because different types behave differently: a domestic SEPA payment might achieve 99 percent STP, while a complex cross-border payment with manual compliance checks might achieve 85 percent. The main causes of STP breaks are missing or incorrect data, such as an invalid IBAN or a missing beneficiary address, sanctions alerts, and liquidity or limit failures. Improving STP is a common BA objective: it involves better validation at the channel, richer reference data, clearer customer guidance, and smarter exception handling. When you propose a change, always estimate its impact on STP, because that is the number operations and finance care about.

A payment exception queue is the worklist where payments that cannot be processed automatically are held for manual handling by operations staff. Payments land in the exception queue for many reasons: a sanctions screening alert, a failed validation such as an invalid account number, a missing beneficiary address, a limit breach, a liquidity shortfall, or a technical error such as a rejected message from a clearing system. Each item in the queue shows the payment details, the reason it failed, and the actions available: repair and resubmit, release, return to sender, or escalate. Operations teams work the queue in priority order, guided by service level agreements based on value date and cut-off times, because a payment that misses its cut-off may settle a day late. Good exception handling design includes clear reason codes, the ability to see the full payment history, four-eyes approval for high-value repairs, and automatic escalation when an item ages beyond its SLA. The exception queue is also a source of management information: recurring reasons point to upstream problems, such as a channel that accepts invalid IBANs or a mapping error. For a BA, the exception queue is a core functional area: you define the queue structure, the workflow states, the repair screens, and the reporting that helps operations and product teams reduce exception volumes.

A payment operations dashboard is a real-time view of payment processing health that lets operations teams see what is happening and act quickly when something goes wrong. It typically shows volumes by payment type, channel, and currency; the straight through processing rate; the size and ageing of exception queues; payments approaching cut-off times; settlement and nostro balances; and the status of connections to clearing systems. Good dashboards use traffic-light indicators: green for normal, amber for warning, and red for breach, so an operator can spot a problem at a glance. They also support drill-down: clicking on a red exception count shows the underlying payments and their failure reasons. Dashboards serve different audiences: operators need live queues and alerts, team leads need staffing and SLA views, and management needs trends and cost metrics. They are usually built on data from the payment hub, enriched with reference data and fed by streaming or near-real-time updates. For a BA, dashboard requirements cover the metrics to display, the data sources, refresh frequency, alert thresholds, user roles, and the actions an operator can take from the dashboard, such as reprioritizing a queue or pausing a payment type. A well-designed dashboard turns a flood of payment data into decisions.

A payments BA writes several types of documents, each serving a different audience. The Business Requirements Document, or BRD, captures what the business needs and why: the problem, the objectives, the scope, the stakeholders, and the high-level requirements. It is written in business language and signed off by product owners and business sponsors. The Functional Specification Document, or FSD, translates the BRD into detailed system behavior: field definitions, validation rules, state machines, message mappings, error handling, and screen layouts. Developers build from the FSD and testers write test cases from it. User stories are used in agile teams: short statements in the form of as a user, I want, so that, with acceptance criteria that define done. A payments epic, such as support ISO 20022, breaks into stories for message mapping, validation, and screening. Process flows, drawn in BPMN or simple swimlane diagrams, show how a payment moves through people and systems, including decision points and exception paths. Other common documents include data mapping spreadsheets, gap analyses, and traceability matrices linking requirements to tests. The key skill is choosing the right document for the audience and keeping them consistent: a requirement in the BRD must trace to the FSD, to a user story, and to a test case.

A payment test case is a documented scenario that verifies a specific behavior of a payment system, with defined inputs, expected results, and pass or fail criteria. A good test case starts with a clear objective, for example verifying that a SEPA payment with an invalid IBAN is rejected with the correct error code. It specifies the preconditions, such as the test account setup and reference data; the test steps, such as entering the payment details and submitting; the test data, including amounts, currencies, and dates; and the expected result, such as the exact error message and the payment status. Payment test cases cover happy paths, such as a standard domestic payment settling on time, and edge cases, such as a payment on a bank holiday, a payment above a limit, a payment to a sanctioned country, and a payment with a special character in the beneficiary name. They also cover non-functional aspects such as performance under load and correct handling of duplicate messages. Test cases are organized into test suites by payment type and are traced back to requirements so that every requirement has at least one test. For a BA, writing test cases is a core skill: it forces you to think through the requirement completely, and the test cases you write are often the basis for user acceptance testing with the business.

Testing a payment flow means verifying that a payment moves correctly from initiation to settlement, including all the checks and branches along the way. Start by mapping the flow: the channel, the hub, screening, the clearing system, and settlement, with every decision point identified. Then design test cases for the happy path, where a valid payment settles on time with the correct amount, fees, and value date. Next, test the negative paths: invalid account numbers, missing mandatory fields, amounts over limits, payments after cut-off, and payments to sanctioned beneficiaries. Test the integration points: message formats, acknowledgements, and status updates from the clearing system. Test exception handling: a payment that fails screening should land in the exception queue with the right reason code, and a repaired payment should resubmit correctly. Test idempotency by submitting the same payment twice and confirming it is processed only once. Test with realistic data, including different currencies, countries, and character sets, and test boundary conditions such as the maximum amount and the last minute before cut-off. Finally, run end-to-end tests in an environment that mirrors production, including the core banking and general ledger postings, and reconcile the results. Document every defect with steps to reproduce, expected versus actual behavior, and severity.

User Acceptance Testing, or UAT, is the phase where business users verify that a payment system meets their requirements before it goes live. Unlike system testing, which is done by testers against specifications, UAT is done by the people who will actually use the system: operations staff, product managers, and sometimes customers. In payments, UAT typically covers end-to-end scenarios: submitting payments through each channel, checking that screening and exception handling work as expected, verifying that settlements and accounting entries post correctly, and confirming that reports and dashboards show the right data. UAT is planned around business scenarios rather than technical cases: a corporate customer paying salaries, a high-value payment that needs four-eyes approval, or a payment that hits a sanctions alert. Testers record pass or fail against acceptance criteria defined in advance, and defects are triaged by severity: a defect that blocks settlement is critical, while a cosmetic issue can be deferred. Sign-off is formal: the business owner confirms the system is fit for purpose, and this sign-off is often required by auditors and regulators before go-live. For a BA, UAT is a major responsibility: you write the test scenarios, support the testers, triage defects, and manage the sign-off process. A well-run UAT is the last line of defense against a bad release.

A payment workshop is a facilitated session where a BA brings business stakeholders, operations staff, and technical teams together to define requirements for a payment change. It is more effective than one-to-one interviews for payments because a payment flow crosses many teams, and a workshop surfaces disagreements early. A typical workshop starts with the current state: how does the payment flow work today, and where does it break? Then it moves to the future state: what should change, and what does success look like? Key questions include: which payment types and channels are in scope, and which are out of scope? What are the cut-off times and value dating rules? What validation should happen at the channel versus the hub? What happens when screening flags a payment, and who decides whether to release it? What are the fee and charging rules? What reports and reconciliations are needed? What are the non-functional requirements, such as volumes, performance, and availability? Good workshops use process flows on a whiteboard, real payment examples, and edge cases such as a payment on a public holiday. The BA's job is to keep the discussion focused, capture decisions and open actions, and turn the output into requirements. A well-run workshop can resolve in hours what would take weeks of email.

A payments BA typically starts as a junior or associate BA, supporting senior colleagues on a single payment type or project, writing test cases, and documenting current-state processes. After two to three years, they become a mid-level BA, owning requirements for a payment product or a workstream such as ISO 20022 migration, running workshops, and managing stakeholders. Senior BAs lead large programs such as a payment hub replacement or a new instant payments launch, mentor juniors, and influence product strategy. From there, the path branches. Some move into product management, owning the roadmap for a payments product. Others become solution architects, designing the technical target state. Some move into program or delivery management, running large transformation programs. Others specialize, becoming experts in compliance, sanctions, or a specific scheme such as SWIFT or SEPA. The skills that accelerate progression are deep domain knowledge of payment rails and schemes, strong stakeholder management, the ability to write precise specifications, and an understanding of regulation and risk. Certifications such as the Certified Payments Professional or scheme-specific training help, but hands-on experience on major migrations is what hiring managers value most. The demand for payments BAs is strong and growing, driven by ISO 20022 migration, instant payments, and open banking.

Every SWIFT MT message is built from up to five blocks, each wrapped in curly brackets and numbered 1 to 5. Block 1 is the basic header. It identifies the sender, the session and the sequence number, and it is mandatory on every message. Block 2 is the application header. It states the message type, such as 103 or 202, and whether the message is incoming or outgoing, and it is also mandatory. Block 3 is the user header. It is optional and carries extra routing and validation data, such as a user reference or a service identifier. Block 4 is the text block. It holds the business data of the payment, organised as tagged fields such as field 20, field 32A and field 59. Block 5 is the trailers block. It holds the checksum and other system trailers, and it is added by SWIFT itself. The order is always 1, 2, 3, 4, 5. A reader who can recognise each block can split any raw message into its envelope, its routing data, its business content and its integrity check, which is the first skill every payments operations analyst needs. In the BNPP example in this course, the same block layout appears on every MT103 and MT202 COV, so learning it once lets you read the whole payment chain.

Block 1, the basic header, is mandatory and has five fields packed into one short string. It always starts with {1: followed by the application identifier, which is F for FIN, then the service identifier, which is 01 for FIN. Next comes the logical terminal address of the sender, a 12 character BIC plus branch code, for example BNPAFRPPAXXX for BNP Paribas Paris. Then comes the four digit session number, and finally the six digit sequence number of the message within that session. A full example is {1:F01SOGEFRPPAXXX0070970817}, where SOGEFRPPAXXX is the sender, 0070 is the session number and 970817 is the sequence number. The session number changes when a new SWIFT session starts, and the sequence number increases by one for each message sent in that session, so the pair gives every message a unique position in the sender's output stream. If two messages ever show the same session and sequence number from the same sender, one of them is a duplicate. Operations teams use Block 1 to prove which institution sent a message, to trace it through logs, and to detect duplicates before the business data in Block 4 is even read.

Block 2, the application header, looks different depending on whether the message is entering SWIFT or leaving it. An input header starts with the letter I and describes a message a bank is sending into the network. It carries the message type, the BIC of the receiver, and the priority, for example {2:I103BSCHESMMXXXXN}, which means an outgoing MT103 to Banco Santander Madrid at normal priority. An output header starts with the letter O and describes a message SWIFT has delivered to a bank. It is longer because it adds the history of the message inside the network. It carries the message type, the input time, the Message Input Reference date, the sender's logical terminal address, the session number, the sequence number, the output date, the output time and the priority. An example is {2:O1031734150713DEUTDEFFBXXX00739698421607131634N}, an MT103 that arrived from Deutsche Bank. The practical difference is simple. Input headers tell you what your bank sent and to whom. Output headers tell you what arrived, when it entered SWIFT, who sent it, and when SWIFT delivered it. When an operations team investigates a missing payment, the output header is the first place they look, because it proves the message reached the receiver and records the exact times.

Block 3, the user header, is optional on most MT messages and carries extra information that does not fit in the business fields of Block 4. It is a set of tagged items inside curly brackets, for example {3:{103:TGT}{108:OPTUSERREF16CHAR}}. Each tag has a three digit number and a value. Tag 103 identifies a FINCopy service, telling SWIFT to send a copy of the message to a central system as well as to the receiver. Tag 108 is a message user reference, a free reference of up to 16 characters that the sender chooses, which helps the sender match the message to its own internal system. Tag 111 is a service type identifier, tag 115 is used for a previous session and sequence reference, tag 119 is the validation flag that marks an MT202 as a cover payment, and tag 121 carries the Unique End to end Transaction Reference, or UETR, used for SWIFT gpi tracking. Block 3 is optional except in one case. When a message goes through FINCopy, tag 103 becomes mandatory, because SWIFT needs to know which copy service should receive the message. For most day to day MT103 traffic, Block 3 is either absent or carries only a user reference and a UETR. Analysts should always check Block 3 before assuming a message is ordinary, because a 119 flag or a FINCopy service code changes how the message must be handled.

Block 4, the text block, is the business heart of an MT message. It holds all the payment data, organised as tagged fields, and it is wrapped as {4: ... -}. Each field starts with a colon, a two digit field number, an optional letter for the field option, and another colon, for example :20: for the transaction reference, :32A: for the value date and settled amount, and :59: for the beneficiary customer. The field tag is followed by the value on the same line or on the following lines, depending on the field. Multi line fields such as 50, 59 and 70 use line breaks inside the value, with each line limited to 35 characters. Amounts use a comma as the decimal separator, so USD 367,574.90 is written as USD367574,90. Dates use the format YYMMDD, so 18 July 2024 is written as 180724. A field can be mandatory or optional, and a message that misses a mandatory field is rejected by SWIFT validation before it is delivered. Some fields can repeat, such as field 71F for charges, and some appear only in specific situations, such as field 36 for an exchange rate. Reading Block 4 means reading it field by field, checking each tag against the message specification, and confirming that the values are consistent with each other. The amount in field 32A, the amount in field 33B, the charges in field 71F and the beneficiary account in field 59 must all tell the same story.

Block 5, the trailers block, sits at the end of an MT message and holds system data added by SWIFT, not by the sending bank. Its most important trailer is the checksum, written as {CHK: followed by 12 hexadecimal characters and a closing bracket, for example {5:{CHK:D628FE0165A7}}. The checksum is calculated by SWIFT from the full content of the message. When the receiving bank or SWIFT itself recalculates the checksum and compares it with the value in Block 5, any difference proves that the message was altered or corrupted in transit, even by a single character. Block 5 can also carry other trailers, such as a test and training message marker, a possible duplicate emission marker, a delayed message marker, or a message reference used when a message is split. The trailers block is optional in the sense that a sender does not write it. SWIFT adds it during processing, and the receiver uses it to verify integrity. For an operations analyst, the practical lesson is simple. Never edit a raw message and resend it with the old checksum, because the checksum will no longer match and the message will fail validation. If a message must be corrected, it must be rebuilt and sent as a new message with a new reference, and the original should be cancelled or left to be rejected. The checksum is what makes an MT message tamper evident from end to end.

Take the worked example from this course and read it block by block. The message starts {1:F01SOGEFRPPAXXX0070970817}, which is Block 1. It tells you the sender is Societe Generale Paris, SOGEFRPPAXXX, in session 0070, sequence 970817. Next comes {2:O1031734150713DEUTDEFFBXXX00739698421607131634N}, Block 2 output. It tells you this is an MT103 that arrived from Deutsche Bank, DEUTDEFF, at 17:34 on 15 July 2013. Then {3:{103:TGT}{108:OPTUSERREF16CHAR}} is Block 3. Tag 103 shows a FINCopy service and tag 108 is the sender's own user reference. Then Block 4 begins with {4: and the business fields follow. Field :20:UNIQUEREFOFTRX16 is the transaction reference. Field :23B:CRED shows a standard credit transfer. Field :32A:180724EUR735927,75 gives the value date 18 July 2024, the currency EUR, and the settled amount 735,927.75. Field :33B:EUR735927,75 repeats the instructed amount. Field :50A:/DE37500700100950596700 with DEUTDEFF identifies the ordering customer account. Field :59:/FR7630003034950005005419318 with CHARLES DUPONT COMPANY gives the beneficiary. Field :71A:SHA shows shared charges. The block ends with -} and Block 5 {5:{CHK:D628FE0165A7}} gives the checksum. Read in this order, envelope first and business data second, any MT message becomes a clear story.

A session number is a four digit number in Block 1 and Block 2 that identifies one continuous period during which a bank is connected to the SWIFT network. Each time a bank starts a new session, the session number increases, and within that session every message gets a sequence number that increases by one for each message sent. Together the session number and the sequence number give every message a unique position in that bank's output stream, which is why the combination is called the Message Input Reference when combined with the date and the sender address. Session numbers matter for three practical reasons. First, they let operations teams trace a message through logs and prove exactly when it was sent and in what order. Second, they let SWIFT and the receiving bank detect duplicates, because the same session and sequence number from the same sender should never appear twice. Third, they help recovery after an outage. If a connection drops mid session, the bank and SWIFT can agree on the last sequence number received and resend only the messages after it, instead of resending everything. Session numbers reset or roll over according to SWIFT rules, and they are not the same as the value date or the transaction reference. An analyst investigating a missing payment should always ask for the session and sequence numbers, because they are the fastest way to confirm whether a message left the sender at all.

FIN is the standard SWIFT store and forward messaging service. A bank sends a message into FIN, SWIFT validates it, stores it, and forwards it to the receiver. Only the sender and the receiver see the message, and no third party gets a copy. FINCopy is an extra service built on top of FIN. When a message is sent through FINCopy, SWIFT sends the message to the receiver as normal, and also sends a copy to a third party, usually a central system such as a market infrastructure, a central bank, or a clearing house. The copy is identified in Block 3 by tag 103, which names the FINCopy service, and tag 103 is mandatory on FINCopy messages. A common use is a payment system that needs to see every payment instruction so it can settle the funds centrally. The bank still sends one MT103, but the central system receives its copy automatically and can act on it without the bank sending a second message. The practical difference for operations teams is that a FINCopy message has an extra recipient and an extra obligation. If the copy fails or the central system rejects it, the payment can be blocked even though the receiver got the message. When you see tag 103 in Block 3, always check which service it names and whether that service acknowledged the copy, because the payment is not complete until both the receiver and the copy destination have accepted it.

Message priority is a single character in Block 2 that tells SWIFT how urgently a message should be processed and delivered. There are three values. U stands for urgent. It is used for time critical payments, such as a payment that must settle the same day or a message that corrects an error on a payment already in flight. Urgent messages jump ahead of normal traffic in the delivery queue. N stands for normal. It is the default for almost all MT103 and MT202 traffic, including the BNPP payment in this course, where the priority is N. Normal messages are delivered in the order they arrive, and for most commercial payments that is fast enough. S stands for system. It is reserved for SWIFT system messages and for traffic between SWIFT and its own services, and banks do not use it for customer payments. Priority does not change the value date, the charges, or the business content of the message. It only changes the order in which SWIFT processes the queue. An operations team should use U sparingly, because marking every payment urgent defeats the purpose and can attract extra attention from the receiver. The right habit is to send routine payments at N, reserve U for genuine same day deadlines, payment investigations that unblock a stuck payment, and cancellations that must arrive before the original payment is processed. If a payment is late, checking the priority is a quick first step, because an N message sent late in the day may simply be waiting in the queue.

Field 20 is the Transaction Reference Number, and it is the first field in Block 4 of every MT103. It is mandatory, it has the format 16x, which means up to 16 characters of letters, digits and a few symbols, and it must be unique for the sender. In the BNPP example the reference is 103REF405775, and it appears on the MT103 announcement and on the related MT202 COV as field 21, so that every message in the same payment can be linked together. The reference is chosen by the sending bank, not by SWIFT, and it usually comes from the bank's own payment system. Its job is identification. When the beneficiary bank, a correspondent, or the customer asks where a payment is, the reference in field 20 is the key that every system along the chain uses to find it. It also prevents duplicates, because a bank that receives two MT103s with the same field 20 from the same sender in a short period should treat the second as a possible duplicate and investigate before crediting twice. A good reference is unique, stable, and meaningful. It should never be reused for a different payment, never be changed as the payment moves from bank to bank, and never be confused with the UETR, which is a separate global identifier carried in Block 3. If field 20 is wrong or missing, the payment cannot be traced, reconciled, or investigated, which is why SWIFT makes it mandatory on every MT103.

Field 13D is the Date and Time Indication field in an MT103. It is optional, and it carries a date and time that qualifies an event in the life of the payment, such as the time the instruction was executed, the time the funds should be available, or a cut off time agreed with the customer. The field uses a code to say what the date and time means, followed by the date in YYMMDD format and the time in HHMM format, with an optional time zone offset. For example, a value meaning 5 January 2026 at 14:30 can be written with the date 260105 and the time 1430. Field 13D is not the value date. The value date lives in field 32A and drives the accounting. Field 13D is extra timing information that helps the receiver plan its processing, for example by showing when the ordering customer asked for the payment to be released. Because it is optional, many banks leave it out on routine payments, and its absence never blocks a payment. It becomes useful on time sensitive payments, on payments linked to a contract deadline, and on payments where the sender wants to prove when the instruction was created. Operations teams should not invent a value for field 13D. If the sender's system does not hold a genuine date and time for the event, the field should be omitted rather than filled with a guessed value, because a wrong timestamp can mislead an investigation more than a missing one.

Field 23B is the Bank Operation Code, a mandatory field that tells the receiver what kind of transfer this MT103 is. It has the format 4!c, which means exactly four characters, and there are four valid values. CRED stands for a standard credit transfer, and it is the value used for almost all ordinary customer payments, including the BNPP payment of USD 367,574.90 in this course. CRTS stands for a credit transfer for test purposes, used when banks are testing a new connection or a new process and no real funds should move. SPAY stands for a SWIFT payment, a code used for a payment that follows SWIFT's own payment conventions in full. SSTD stands for a standard transfer, used for a payment that follows standard settlement practice. The code matters because the receiver's system uses it to decide how to process the message. A CRTS message must never be treated as a real payment, and a SPAY message may be handled under stricter formatting rules than a CRED message. Most senders use CRED for every live customer payment and never touch the other codes. If field 23B carries a value outside the four allowed codes, SWIFT validation rejects the message before delivery. When you read an MT103, field 23B is one of the first fields to check, because it confirms at a glance whether you are looking at a real payment, a test, or a special type of transfer.

Field 23E is the Instruction Code field in an MT103. It is optional and repeatable, and it carries a four character code that tells the receiver how to handle the payment, plus optional extra text of up to 30 characters. The most common codes are SDVA, which means pay on the value date shown in field 32A and do not pay early, INTC, which means the payment is intra company, REPA, which means the payment relates to a repayment, CORT, which means the payment is made under a corporate trade transaction, HOLD, which means hold the funds and contact the beneficiary, CHQB, which means pay the beneficiary by cheque, PHOB, which means contact the beneficiary by phone, and TELB, which means contact the beneficiary by the most efficient telecommunication method. A payment can carry more than one 23E code, for example SDVA plus REPA, and each code is written on its own line as :23E:SDVA. The codes matter because they change the receiver's behaviour. A HOLD code means the beneficiary bank should not credit the account automatically, and a CHQB code means no account credit should happen at all. Many routine payments carry no 23E at all, and that is normal, because the absence of a code means standard processing. Senders should only add a code when they genuinely need the special handling, because an incorrect code can delay a payment while the receiver asks for clarification. When investigating a payment that was not credited on time, field 23E is worth checking early.

Field 26T is the Transaction Type Code in an MT103. It is optional and has the format 3!c, which means exactly three characters, taken from a SWIFT defined list of transaction types. The code classifies the underlying business reason for the payment, for example a code in the 100 range for a customer transfer, a code for a cheque related transfer, or a code for a specific type of commercial payment. In practice field 26T is rarely used today. Most banks leave it out, and most receivers ignore it, because the business reason is now carried more precisely in field 70, the remittance information, and in the regulatory reporting field 77B. The field survives from an older era of SWIFT messaging, when a short code was the only way to classify a payment for reporting and statistics. It is still valid, and a message that includes it will pass validation if the code is on the allowed list, but including it adds no value to the payment itself and a wrong code can confuse a receiver that still reads it. The practical guidance is simple. Do not add field 26T unless your bank has a specific reporting or bilateral agreement that requires it. If you receive an MT103 that carries field 26T, read it as background classification only, and rely on fields 32A, 33B, 59 and 70 for the real payment facts. Students should know the field exists so they are not surprised when it appears on an old message, but they should not treat it as a core field.

Field 32A is one of the most important fields in an MT103. It is mandatory and it carries three pieces of data in one line: the value date, the currency code, and the interbank settled amount. Its format is 6!n3!a15d, which means six digits for the date, three letters for the currency, and up to 15 digits for the amount with a comma as the decimal separator. For example, :32A:240105USD367554,90 means a value date of 5 January 2024, a currency of US dollars, and a settled amount of USD 367,554.90. The value date is the date on which the funds become available to the receiver for accounting purposes, and it drives interest calculations and nostro reconciliation. The settled amount is the amount that actually moves between banks at this step of the chain, after any charges already deducted. In the BNPP serial example the instructed amount is USD 367,574.90, but after Wells Fargo deducts its USD 20 charge the second MT103 carries field 32A with USD 367,554.90, and after BNY deducts USD 22 the final amount is USD 367,532.90. That is why field 32A can change from one MT103 to the next while the original instruction stays the same. When you read an MT103, always compare field 32A with field 33B. If the two amounts differ, the difference should be explained exactly by the charges in fields 71F and 71G.

Field 33B is the Currency and Instructed Amount field in an MT103. It is optional, and its format is 3!a15d, which means a three letter currency code followed by up to 15 digits with a comma as the decimal separator, for example :33B:USD367574,90. It states the amount the ordering customer originally instructed, before any bank in the chain deducted charges. Field 32A, by contrast, states the interbank settled amount that moves at this step, after charges already taken. The two fields are needed together because they let every bank in the chain see both the original instruction and the amount that is actually arriving. In the BNPP serial example the instructed amount is USD 367,574.90, so field 33B shows USD367574,90 on every MT103 in the chain. Field 32A starts at the same value on the first MT103, drops to USD 367,554.90 on the second after the USD 20 Wells Fargo charge, and drops to USD 367,532.90 on the third after the USD 22 BNY charge. Without field 33B, the beneficiary bank would see only the final reduced amount and would have no way to know that USD 42 of charges had been deducted along the way. That matters for the beneficiary, who may query why the amount received is less than the invoice, and for reconciliation, because the difference between 33B and 32A must equal the sum of the charges in fields 71F and 71G. Field 33B is optional in the standard, but good practice is to include it on every customer payment.

Field 36 is the Exchange Rate field in an MT103. It is optional and has the format 12d, which means up to 12 digits with a comma as the decimal separator, for example :36:1,0875. It states the rate used to convert one currency into another when the instructed currency differs from the settled currency. Field 36 is needed only when a foreign exchange conversion happens inside the payment. If the ordering customer instructs a payment in euros but the interbank settlement happens in US dollars, the bank that performs the conversion records the rate it applied in field 36, so that every bank downstream can check the conversion and the beneficiary can see how the amount was calculated. If there is no conversion, because the instructed currency and the settled currency are the same, field 36 must be left out. In the BNPP example no field 36 appears, because the whole payment is in US dollars from start to finish, so there is nothing to convert. A common mistake is to include field 36 on a same currency payment with a rate of 1, which is wrong and can cause validation problems. Another mistake is to include the rate but forget to make fields 32A and 33B consistent with it. When you read an MT103 that carries field 36, multiply the instructed amount by the rate and check that the result matches the settled amount, allowing for charges. If the numbers do not reconcile, the conversion or the charges need to be investigated before the payment is released.

Field 50a is the Ordering Customer field in an MT103. It is mandatory and it identifies the customer who ordered the payment. The letter after the 50 tells you which option is used, and each option carries the information in a different format. Option A, field 50A, gives the account number and the BIC of the ordering customer's bank, for example :50A:/DE37500700100950596700 followed by DEUTDEFF. It is used when the ordering customer is identified by an account held at a bank. Option F, field 50F, gives the party identifier plus the full name and address of the ordering customer on separate lines, and it is the preferred option when the ordering customer is a person or a company that must be identified precisely for compliance screening. Option K, field 50K, gives the account number plus the name and address of the ordering customer in free text, and it is the older option that predates the structured format of option F. Modern practice is to use 50F for individuals and companies, because sanctions screening and anti money laundering checks need a structured name and address, and to use 50A only when the ordering customer is itself a financial institution. A payment with a vague or missing ordering customer will be stopped by the receiver's compliance filters, so field 50a is one of the first fields a sanctions team checks. Never abbreviate the name, never omit the address on option F or K, and never put the beneficiary in field 50.

Field 51A is the Sending Institution field in an MT103. It is optional and has the format [/34x] plus a BIC, for example :51A:BNPAFRPP, and it names the financial institution that sent the message on behalf of the account owner. In most MT103s field 51A does not appear, because the sender of the message is also the institution that owns the account being debited, so there is nothing extra to say. Field 51A is needed when the institution that physically sends the message is different from the institution whose account is being used. A common case is a bank that sends SWIFT messages through a service bureau or through another bank in its group. Another case is a branch that sends on behalf of its head office. In those cases the sender in Block 1 is the service provider, and field 51A names the real sending institution so the receiver knows whose instruction it is acting on. The distinction matters for reconciliation and for compliance, because the receiver must know which institution is responsible for the payment, not just which terminal sent it. If field 51A is present, the receiver should use it as the sending institution for its records and for any reply or investigation. If it is absent, the sender in Block 1 is the sending institution. Operations teams should never invent a value for field 51A, and they should always check it when a payment arrives from an unexpected BIC, because it may explain why the sender does not match the account holder.

Field 52a is the Ordering Institution field in an MT103. It is optional and it names the financial institution that ordered the payment on behalf of the ordering customer. Option A carries the BIC, for example :52A:BNPAFRPP, and option D carries the name and address in free text. In a serial payment, field 52A is absent from the first MT103 and present from the second onwards, and the reason is simple. The first MT103 is sent by BNPP itself, the ordering institution, so naming it again in field 52A would be redundant. The receiver, Wells Fargo, already knows from Block 1 that BNPP sent the message. The second MT103 is sent by Wells Fargo to Bank of New York Mellon, so without field 52A the receiver would think Wells Fargo was the ordering institution. Field 52A with BNPAFRPP tells BNY that the original order came from BNPP, even though the message in front of it was sent by Wells Fargo. The third MT103, from BNY to Santander, also carries :52A:BNPAFRPP for the same reason. Field 52A therefore preserves the identity of the original ordering institution as the payment passes from bank to bank. That matters for compliance screening, because each bank must screen the true originator, and for investigations, because the beneficiary bank needs to know who to contact if something goes wrong. If field 52A is missing from a second or third MT103, the chain of origin is broken.

Fields 53a and 54a are the correspondent fields in an MT103, and they appear only in a cover payment, never in a serial payment. Field 53a is the Sender's Correspondent. It names the bank that will provide the funds to the receiver on behalf of the sender. Field 54a is the Receiver's Correspondent. It names the bank where the receiver holds its account for this currency. In the BNPP cover example the announcement MT103 from BNPP to Santander carries :53A:PNBPUS3N, which is Wells Fargo, and :54A:IRVTUS3N, which is Bank of New York Mellon. The meaning is that BNPP will fund Santander through Wells Fargo, and Santander's US dollar account is held at BNY. The announcement tells Santander that the money is coming and how it will arrive, but it does not move the money itself. The actual funds move separately through the MT202 COV cover messages. In a serial payment there is no need for fields 53a and 54a, because each MT103 in the chain is itself an instruction to move funds from one bank to the next, so the sender and receiver of each message are the banks that debit and credit. The presence of 53a and 54a is therefore the clearest sign that an MT103 is an announcement in a cover payment, not a serial instruction. If you see 53a and 54a, do not expect the funds to arrive with that message. Look for the matching MT202 COV.

Field 55a is the Third Reimbursement Institution field in an MT103. It is optional and it names a financial institution, other than the sender and the receiver, that will reimburse the receiver for the payment. Option A carries the BIC, for example :55A:PNBPUS3N, and option D carries the name and address. Field 55a is used when the sender does not hold an account with the receiver and does not want to use the normal correspondent chain. Instead, the sender tells the receiver to claim reimbursement from a third bank where the sender does hold funds. For example, BNPP could tell Santander to seek reimbursement from Wells Fargo, its US dollar correspondent, even though Wells Fargo is not the sender or the receiver of that particular MT103. The receiver then sends a claim to the third reimbursement institution, which debits the sender's account and credits the receiver. Field 55a is rare on ordinary customer payments, because most banks prefer the standard serial or cover routes where the funding path is clear from fields 53a, 54a, 56a and 57a. It appears mainly on payments involving banks with no direct account relationship, and on payments where a specific reimbursement arrangement has been agreed in advance. If field 55a is present, the receiver should not expect the funds to come from the sender directly. It should raise a reimbursement claim with the named institution, and it should not credit the beneficiary until that claim is confirmed or until its own risk policy allows early credit.

Field 56a is the Intermediary Institution field in an MT103. It is optional and it names a financial institution that sits between the sender and the receiver in the payment chain and through which the funds must pass. Option A carries the BIC, for example :56A:IRVTUS3N for Bank of New York Mellon, and option D carries the name and address. The intermediary is the next bank that the sender instructs to continue the payment towards the beneficiary bank. In the BNPP serial example the first MT103, from BNPP to Wells Fargo, carries :56A:IRVTUS3N, telling Wells Fargo that after debiting BNPP's account it should credit BNY, the intermediary, and that BNY will take the payment forward to Santander. An intermediary is different from a correspondent. A correspondent is a bank where another bank holds an account, and the relationship is about holding funds. An intermediary is a role in a single payment, and the relationship is about passing the instruction forward. The same bank can be both a correspondent and an intermediary in one payment, as BNY is in the BNPP example. Field 56a is used in serial payments, where each MT103 instructs the next bank in the chain. It is not used in the announcement MT103 of a cover payment, because the announcement does not instruct a chain of banks. It uses fields 53a and 54a instead. If field 56a is wrong, the payment goes to the wrong bank and must be recalled.

Field 57a is the Account With Institution field in an MT103. It is optional and it names the financial institution where the beneficiary's account is held, or where the next bank's account is held. Option A carries the BIC, for example :57A:BSCHESMM for Banco Santander Madrid, and option D carries the name and address. In the BNPP serial example field 57a is present on the first two MT103s and absent from the third, and the reason shows the logic of the chain. The first MT103, from BNPP to Wells Fargo, carries :57A:IRVTUS3N, telling Wells Fargo that the account to be credited at the next step is held at BNY. The second MT103, from Wells Fargo to BNY, carries :57A:BSCHESMM, telling BNY that the beneficiary account is held at Santander. The third MT103, from BNY to Santander, has no field 57a, because Santander is the receiver of that message and it already holds the beneficiary account. There is no next institution to name. The rule is that field 57a names the institution after the receiver. When the receiver is the beneficiary bank itself, there is no institution after it, so the field is omitted. The same logic applies in a cover payment. The announcement MT103 has no field 57a, because the beneficiary account is held by the receiver, Santander. If field 57a names the wrong institution, the payment can be credited to the wrong bank, so operations teams always check it against the beneficiary bank in field 58a and the beneficiary account in field 59.

Field 58a is the Beneficiary Institution field in an MT103. It is optional and it names the financial institution that will ultimately receive the funds for the beneficiary customer. Option A carries the BIC, for example :58A:BSCHESMM for Banco Santander Madrid, and option D carries the name and address. In most customer payments the beneficiary institution is the same as the beneficiary bank, which is the bank where the beneficiary holds its account, so field 58a simply confirms what field 57a already implies. The field becomes important when the two are different. That happens when the beneficiary customer holds its account at a bank that is not directly reachable on SWIFT, and a larger bank acts as its beneficiary institution and passes the funds on through a local system. It also happens when the beneficiary is itself a financial institution and the payment is being made to its account at another bank. In the BNPP example the beneficiary is a Spanish company, not a bank, so field 58a would name Santander as the institution that receives the funds for that company. Field 58a is optional because in a simple payment the receiver of the final MT103 is already the beneficiary institution, and repeating it adds nothing. But when the payment chain is complex, field 58a removes ambiguity about who the final bank is. If field 58a is present and does not match the receiver of the final MT103, the payment needs to be checked before it is credited, because the funds may need to be forwarded one step further.

Field 59a is the Beneficiary Customer field in an MT103. It is mandatory and it identifies the customer who should finally receive the funds. The field starts with the beneficiary account number, written after a slash, followed by the beneficiary name and address on the following lines. In the BNPP example the beneficiary account is the Spanish IBAN ES6300491800132710387658, so the field begins :59:/ES6300491800132710387658 and the next lines give the name of the Spanish company and its address. Option A is not used for field 59. The standard option is field 59 with no letter, carrying the account and the name and address in free text, with each line limited to 35 characters and up to four lines for the name and address. Option F exists for a structured name and address, but the free text form is the one most banks use. The account number must be exact, because a single wrong digit sends the funds to the wrong account or causes the payment to be rejected. The name must match the account holder's name as the beneficiary bank holds it, because a mismatch triggers a compliance check and can delay credit. Operations teams always check field 59 against the invoice or the customer's instruction before releasing a payment. If the account is an IBAN, the country code and check digits must be valid. If the name is abbreviated or misspelt, the beneficiary bank may still credit the account if the account number is correct, but it may also hold the payment for clarification, so accuracy in field 59 saves time at every step.

Field 70 is the Remittance Information field in an MT103. It is optional and it carries the business reason for the payment in free text, so that the beneficiary can match the payment to an invoice, a contract, or an order. Its format is 4 lines of up to 35 characters each, written as :70: followed by the text, for example :70:Invoice 4521, payment for goods, contract 88. Good remittance information is specific, short, and structured. It names the invoice number, the contract or order number, and the goods or services, in that order, and it avoids vague words such as payment or transfer on their own. The beneficiary's accounts team uses field 70 to allocate the funds to the right invoice, and without it they may have to ask the sender for clarification, which delays reconciliation. Field 70 is also read by compliance teams, who check that the stated purpose matches the customer's expected activity. It must never carry information that belongs in another field, such as charges, account numbers, or instructions to the receiver, because those belong in fields 71A, 59 and 72. Field 70 is limited to four lines, so senders should prioritise the invoice number above all else. If the remittance information is longer than four lines, the sender should use a structured reference or ask the beneficiary to agree a shorter code. A payment with clear field 70 data is reconciled the same day. A payment with missing or vague field 70 data can sit unallocated for days.

Fields 71A, 71F and 71G together describe who pays the charges on an MT103 and how much has already been deducted. Field 71A is the Details of Charges field. It is mandatory and has three possible values. BEN means the beneficiary pays all charges, so every bank in the chain deducts its fee from the amount. OUR means the ordering customer pays all charges, so the full instructed amount must reach the beneficiary and each bank claims its fee separately. SHA means the charges are shared, so the ordering customer pays the sender's charges and the beneficiary pays the receiver's and any intermediary charges. The BNPP example uses SHA. Field 71F is the Sender's Charges field. It is optional and repeatable, and it records each charge already deducted, with the currency and the amount, for example :71F:USD20,00 for the USD 20 Wells Fargo charge. A second :71F:USD22,00 records the USD 22 BNY charge. Field 71G is the Receiver's Charges field. It is optional and it records the charges the receiver will deduct before crediting the beneficiary. The rule that ties them together is simple. The instructed amount in field 33B minus all the charges in fields 71F and 71G must equal the settled amount in field 32A. In the BNPP example USD 367,574.90 minus USD 20 minus USD 22 equals USD 367,532.90, which is exactly the final settled amount. If the numbers do not add up, the payment must be investigated before it is released.

Fields 72, 77B and 77T are three different free text fields in an MT103, and each has a distinct job. Field 72 is Sender to Receiver Information. It is optional, it has up to six lines of 35 characters, and it carries instructions from the sender bank to the receiver bank that do not fit in any other field. Each line starts with a code, such as /ACC/ for account information, /INS/ for the instructing bank, /BNF/ for information for the beneficiary, /REC/ for information for the receiver, and /RFB/ for a reference for the beneficiary. A common use is /BNF/ followed by a message for the beneficiary, or /ACC/ followed by instructions about which account to credit. Field 77B is Regulatory Reporting. It is optional, it has up to three lines of 35 characters, and it carries information that a regulator requires, such as a balance of payments code or a reporting code for a specific country. It is used only when the sender or receiver country requires it, and the codes come from the regulator, not from SWIFT. Field 77T is Envelope Contents. It is optional and it carries the contents of an envelope that accompanies the payment, such as a document reference or a code that identifies an attached message. It is rarely used on ordinary commercial payments. The key point is never to mix them up. Instructions to the receiver go in field 72, regulatory codes go in field 77B, and envelope data goes in field 77T. Putting a regulatory code in field 72 can cause the receiver to miss it, and putting an instruction in field 77B can cause a reporting failure.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. In the serial method a single payment instruction travels from bank to bank in a chain, and each bank passes it to the next until it reaches the beneficiary bank. In the BNPP example a French company, customer of BNP Paribas Paris, BNPAFRPP, sends USD 367,574.90 to a Spanish company, customer of Banco Santander Madrid, BSCHESMM, whose account is ES6300491800132710387658. BNPP does not hold an account with Santander, so it uses its US dollar correspondent, Wells Fargo, PNBPUS3N. BNPP sends the first MT103 to Wells Fargo, instructing it to debit BNPP's account and credit Bank of New York Mellon, IRVTUS3N, which is Santander's US dollar correspondent. Wells Fargo sends the second MT103 to BNY, instructing it to debit Wells Fargo's account and credit Santander. BNY sends the third MT103 to Santander, informing it that its account has been credited. Each MT103 is both an instruction and a record. The first two tell the receiver to move funds, and the third tells the beneficiary bank the funds have arrived. Only one message type is used, the MT103, and only one message moves at each step. The funds move in the same direction as the messages, from BNPP to Wells Fargo to BNY to Santander, and the amount falls slightly at each step as each bank deducts its charge. That is the serial method in full, one chain, three messages, and one continuous flow of funds.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The first MT103 in the BNPP serial payment is sent by BNP Paribas Paris, BNPAFRPP, to Wells Fargo, PNBPUS3N. It is a genuine instruction to move funds, not a notification. Field 20 carries the transaction reference 103REF405775. Field 23B carries CRED for a standard credit transfer. Field 32A carries the value date, the currency USD, and the interbank settled amount USD 367,574.90, which at this first step equals the full instructed amount because no charge has been deducted yet. Field 33B also carries USD 367,574.90 as the instructed amount. Field 50 identifies the French ordering customer. Field 56A carries IRVTUS3N, Bank of New York Mellon, as the intermediary institution, telling Wells Fargo where to send the funds next. Field 57A carries IRVTUS3N as well, because the account to be credited at the next step is held at BNY. Field 59 carries the beneficiary account ES6300491800132710387658 and the name of the Spanish company. Field 71A carries SHA for shared charges. There is no field 52A, because BNPP is both the sender and the ordering institution, so naming itself would be redundant. There is no field 53a or 54a, because those fields belong to cover payments, not serial payments. The message tells Wells Fargo to debit BNPP's US dollar account and to credit BNY, and Wells Fargo then creates the second MT103 to carry the payment forward.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The second MT103 in the BNPP serial payment is sent by Wells Fargo, PNBPUS3N, to Bank of New York Mellon, IRVTUS3N. Wells Fargo creates it after receiving the first MT103 from BNPP and debiting BNPP's account. Field 20 carries a new reference chosen by Wells Fargo, because each bank uses its own reference for the message it sends. Field 23B carries CRED. Field 32A carries the value date, USD, and the interbank settled amount USD 367,554.90, which is USD 367,574.90 minus the USD 20 charge Wells Fargo deducted. Field 33B still carries USD 367,574.90, the original instructed amount, so that BNY can see what was deducted. Field 50 still identifies the French ordering customer. Field 52A carries BNPAFRPP, telling BNY that the original ordering institution was BNPP, even though the message was sent by Wells Fargo. Field 56A is no longer needed in the same way, because BNY is the receiver and the next step is Santander itself. Field 57A carries BSCHESMM, telling BNY that the beneficiary account is held at Santander. Field 59 still carries the beneficiary account ES6300491800132710387658 and the Spanish company name. Field 71A carries SHA, and field 71F carries USD 20, recording the charge Wells Fargo took. The message tells BNY to debit Wells Fargo's account and to credit Santander, and BNY then creates the third MT103 to complete the chain.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The third MT103 in the BNPP serial payment is sent by Bank of New York Mellon, IRVTUS3N, to Banco Santander Madrid, BSCHESMM. It is different in character from the first two, because it is not an instruction to debit an account and send funds onward. It is a notification that BNY has credited Santander's account. Field 20 carries a new reference chosen by BNY. Field 23B carries CRED. Field 32A carries the value date, USD, and the interbank settled amount USD 367,532.90, which is USD 367,574.90 minus the USD 20 Wells Fargo charge minus the USD 22 BNY charge. Field 33B still carries USD 367,574.90, the original instructed amount. Field 50 still identifies the French ordering customer. Field 52A carries BNPAFRPP, confirming that BNPP was the original ordering institution. Field 57A is absent, because Santander is the receiver and it already holds the beneficiary account, so there is no next institution to name. Field 59 carries the beneficiary account ES6300491800132710387658 and the Spanish company name, so Santander knows exactly which customer to credit. Field 71A carries SHA, and field 71F appears twice, once for USD 20 and once for USD 22, recording both charges deducted along the chain. On receipt, Santander credits the Spanish company's account with USD 367,532.90 and the serial payment has reached the beneficiary.

Field 52A, the ordering institution, appears in the second and third MT103s of a serial payment but not in the first, and the reason is that the first message needs no reminder of who ordered the payment. The first MT103 is sent by BNP Paribas Paris, BNPAFRPP, which is itself the ordering institution. The receiver, Wells Fargo, can see from Block 1 that BNPP sent the message, so adding :52A:BNPAFRPP would repeat information the receiver already has. The second MT103 is sent by Wells Fargo to Bank of New York Mellon. If it had no field 52A, BNY would naturally assume that Wells Fargo was the ordering institution, because Wells Fargo is the sender in Block 1. Field 52A with BNPAFRPP corrects that assumption and tells BNY that the original order came from BNPP, and that Wells Fargo is only passing it forward. The third MT103 is sent by BNY to Santander, and the same logic applies. Without field 52A, Santander would think BNY ordered the payment. With :52A:BNPAFRPP, Santander knows the true originator. Preserving the ordering institution matters for compliance, because each bank must screen the true originator against sanctions lists, and for investigations, because the beneficiary bank needs to know who to contact if the payment fails. The rule is simple. The bank that originates the payment never names itself in field 52A. Every bank after it must name the originator.

Field 57A, the Account With Institution, disappears in the third MT103 of the BNPP serial payment because there is no institution left to name. Field 57a always names the institution after the receiver, the place where the next account in the chain is held. In the first MT103, from BNPP to Wells Fargo, field 57A carries IRVTUS3N, Bank of New York Mellon, because the next account to be credited is held at BNY. In the second MT103, from Wells Fargo to BNY, field 57A carries BSCHESMM, Banco Santander Madrid, because the next account to be credited is the beneficiary account held at Santander. In the third MT103, from BNY to Santander, the receiver is Santander itself, and Santander already holds the beneficiary account ES6300491800132710387658. There is no next institution, so field 57A has nothing to say and is omitted. The same logic explains why the announcement MT103 in a cover payment has no field 57A. The beneficiary account is held by the receiver, Santander, so there is no onward institution to name. The disappearance of field 57A is therefore a useful signal when reading a chain. If field 57A is present, the payment still has at least one more bank to pass through. If it is absent and the receiver is the beneficiary bank, the payment has reached the end of the chain and the next step is to credit the customer account named in field 59.

In a serial payment each bank in the chain deducts its charge from the amount as the payment passes through, and field 71F records each deduction so that the final amount can be reconciled. The BNPP example uses SHA, shared charges, and the instructed amount is USD 367,574.90. The first MT103, from BNPP to Wells Fargo, carries no field 71F, because no intermediary has taken a charge yet and the settled amount in field 32A equals the instructed amount in field 33B. Wells Fargo deducts USD 20 for its service, so the second MT103 carries field 32A with USD 367,554.90 and one field 71F with USD 20. Bank of New York Mellon then deducts USD 22, so the third MT103 carries field 32A with USD 367,532.90 and two field 71F entries, one for USD 20 and one for USD 22. Field 71F is repeatable, which means each charge gets its own line, and the full history of deductions travels with the payment to the beneficiary bank. Santander can then check the arithmetic. USD 367,574.90 minus USD 20 minus USD 22 equals USD 367,532.90, which matches field 32A exactly. If the numbers do not add up, Santander knows a charge is missing or wrong and can query it before crediting the customer. With OUR charges the arithmetic is different, because the ordering customer pays all charges separately and the full amount must arrive. With BEN charges every bank deducts and the beneficiary receives the reduced amount. Field 71F is what makes the deductions transparent.

Field 33B is needed alongside field 32A because the two fields answer different questions, and a payment chain needs both answers. Field 32A carries the interbank settled amount, which is the amount that actually moves between the two banks at this step of the chain, after any charges already deducted. Field 33B carries the instructed amount, which is the amount the ordering customer originally asked to send, before any charges were deducted. In the BNPP serial example the instructed amount is USD 367,574.90 on every MT103, so field 33B never changes. Field 32A starts at USD 367,574.90 on the first MT103, falls to USD 367,554.90 on the second after the USD 20 Wells Fargo charge, and falls to USD 367,532.90 on the third after the USD 22 BNY charge. Without field 33B, Santander would receive only USD 367,532.90 and would have no way to know that the customer had instructed USD 367,574.90 and that USD 42 had been deducted as charges. The beneficiary might then complain that the payment is short, and Santander would have no evidence to explain the difference. With field 33B and the field 71F entries, Santander can show the beneficiary the full calculation and prove that the deductions were legitimate. Field 33B is optional in the SWIFT standard, but on a customer payment it should always be included, because it is the only field that preserves the original instruction all the way to the beneficiary bank.

An outgoing MT103 and an incoming MT103 can look almost identical, but they mean different things, and confusing them is a common operations mistake. An outgoing MT103 is an instruction from a bank to its correspondent to debit its account and to move funds onward. The first MT103 in the BNPP serial example, from BNPP to Wells Fargo, is an outgoing instruction. It tells Wells Fargo to debit BNPP's US dollar account and to credit Bank of New York Mellon. The second MT103, from Wells Fargo to BNY, is also an outgoing instruction. An incoming MT103 is a notification that arrives at a bank from its correspondent. The third MT103 in the BNPP example, from BNY to Santander, is an incoming notification for Santander. It does not instruct Santander to debit an account and send funds onward. It informs Santander that BNY has already credited Santander's account, and Santander's job is to credit the beneficiary customer account ES6300491800132710387658. The difference is visible in the fields. An outgoing instruction in the middle of a chain carries field 56a or 57a pointing to the next bank. An incoming notification at the end of the chain has no field 57a, because there is no next bank. Operations teams must check the direction before acting. Treating a notification as an instruction can cause a double payment, and treating an instruction as a notification can leave funds sitting unprocessed while the beneficiary waits.

If a bank in the middle of a serial payment chain rejects the payment, the chain stops at that bank and the funds must be returned backwards along the path they came from. Suppose Wells Fargo rejects the BNPP payment because the beneficiary name fails a sanctions screen or the account details are incomplete. Wells Fargo does not forward the payment to Bank of New York Mellon, and it does not create the second MT103. Instead it returns the funds to BNPP and sends a message explaining the rejection, usually an MT199 free format message, or an MT192 if it is cancelling a payment already sent. BNPP then credits its French customer or holds the funds while it asks the customer for corrected details. The rejection can also happen at BNY, which would return the funds to Wells Fargo, which would return them to BNPP. Each return is a separate movement, and each bank must reconcile its nostro account to confirm the funds came back. The beneficiary bank, Santander, never sees the payment at all, because the chain broke before it reached Santander. The customer experiences this as a delay of several days, because each return step takes the same time as a forward step. The most common reasons for rejection are a sanctions match, a missing or invalid beneficiary account, a value date that has already passed, or a currency the receiving bank cannot process. The lesson for senders is to validate the beneficiary details and run sanctions screening before the first MT103 is sent, because a rejection in the middle of a chain is slower and more expensive to fix than a rejection at the start.

A serial payment is generally slower than a cover payment, because each bank in the chain must receive, process, and forward the payment before the next bank can start. In the BNPP example the payment passes through three MT103s, BNPP to Wells Fargo, Wells Fargo to BNY, and BNY to Santander. If each bank takes a few hours to process, including sanctions screening, account validation, and cut off times, the total can easily reach one to two business days, and it can reach three days if a bank in the chain is in a different time zone or if the payment arrives after that bank's cut off. A cover payment can be faster, because the announcement MT103 travels directly from BNPP to Santander, so Santander knows the payment is coming before the funds arrive through the cover chain. If Santander trusts BNPP and the amount is within its threshold, it can credit the beneficiary on the announcement alone, sometimes on the same day. The serial method has no such shortcut, because Santander only learns about the payment when the third MT103 arrives at the end of the chain. The speed difference depends on the banks involved, the time zones, the cut off times, and whether any bank holds the payment for a compliance check. For urgent payments, banks often prefer the cover method or use SWIFT gpi tracking to monitor each step. For routine payments where speed is less important, the serial method is simpler to operate because it uses only one message type and one continuous flow.

The serial method is called the American method because it developed from the way US banks traditionally handled cross border payments through their correspondent networks. In the United States, banks have long held accounts with each other and passed payment instructions from one bank to the next in a chain, with each bank debiting the previous bank and crediting the next. That step by step approach matched the structure of the US banking system, where a payment often passed through several domestic banks before it left the country. The cover method, by contrast, is called the European method, because European banks developed a practice of sending the payment instruction directly to the beneficiary bank and settling the funds separately through correspondents. The names describe history, not rules. An American bank can use the cover method, and a European bank can use the serial method, and many banks use both depending on the currency, the corridor, and the relationship with the beneficiary bank. In the BNPP example the serial method is used even though BNPP is French, which shows that the choice is driven by the payment route, not by the nationality of the bank. The terms are still useful as shorthand. When someone says American method, they mean one message moving party to party in a chain. When someone says European method, they mean two messages, an announcement and a cover. Knowing both terms helps you follow conversations with practitioners who use them interchangeably with serial and cover.

The value date in field 32A is the date on which the funds become available to the receiver for accounting purposes, and in a serial payment it can stay the same or move forward as the payment passes from bank to bank. In the BNPP example the value date is set by BNPP on the first MT103, and each bank in the chain is expected to honour it if the payment arrives in time. In practice, if Wells Fargo receives the payment after its cut off time, it may value date the second MT103 for the next business day, because it cannot credit BNY with same day value after its own books have closed. BNY may then do the same, so Santander receives the funds a day later than BNPP intended. The value date also drives interest. If a bank credits the next bank late, it may owe interest for the delay, and the value date is the evidence used to calculate it. Operations teams check the value date on every MT103 they receive, because a value date in the past can mean the payment is late and interest may be due, while a value date in the future can mean the funds should not be released yet. The instructed amount in field 33B does not carry a value date, so field 32A is the only place the value date appears. A serial payment that crosses time zones is especially sensitive to value dates, because a payment sent in the afternoon in Paris may arrive in the morning in New York on the same calendar day but after the New York cut off. Good practice is to agree the value date with the customer up front and to monitor it at each step.

Each bank in a serial chain knows which account to debit and which to credit from the combination of the sender, the receiver, and the fields in the MT103 it receives. When BNPP sends the first MT103 to Wells Fargo, Wells Fargo knows to debit BNPP's US dollar account, because that is the account BNPP holds with Wells Fargo, and the sender in Block 1 is BNPP. Field 57A tells Wells Fargo to credit Bank of New York Mellon, because BNY is where the next account is held. When Wells Fargo sends the second MT103 to BNY, BNY knows to debit Wells Fargo's account, because Wells Fargo is the sender, and field 57A tells BNY to credit Santander. When BNY sends the third MT103 to Santander, Santander knows to credit the beneficiary account ES6300491800132710387658 named in field 59, because the funds have already been credited to Santander's account at BNY. The nostro and vostro account structure makes this work. Each bank holds a nostro account with its correspondent, and the correspondent holds a vostro account for that bank. A debit to the nostro at one end is a credit to the vostro at the other end, so the books balance. If any field is wrong, the debit or credit goes to the wrong account. That is why operations teams reconcile every MT103 against their account records before posting, and why a payment with a missing or incorrect field 57A is held for investigation rather than processed automatically.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The serial method has four main risks. The first is delay. Because each bank must process the payment before the next bank can start, a hold at any step delays every step after it, and a payment can take two or three days to reach the beneficiary. The second is opacity. The beneficiary bank only learns about the payment when the final MT103 arrives, so it cannot warn the beneficiary in advance, and the ordering customer cannot easily track where the payment is. The third is charge uncertainty. Each bank deducts its fee as the payment passes through, so the final amount the beneficiary receives depends on how many banks are in the chain and what each one charges. In the BNPP example the beneficiary receives USD 367,532.90 instead of USD 367,574.90, a difference of USD 42, and the beneficiary has no control over that. The fourth is rejection in the middle of the chain. If Wells Fargo or BNY rejects the payment, the funds must be returned step by step, which takes as long as the forward journey and can leave the customer waiting for days. There is also a risk of duplicate credit if a bank forwards a payment and then forwards it again by mistake, which is why field 20 and the session and sequence numbers are checked on every message. The serial method remains widely used because it is simple and it works on a single message type, but banks that need speed, transparency, or a guaranteed final amount often prefer the cover method with SWIFT gpi tracking.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. In the cover method a payment uses two messages instead of one. The first is the announcement, an MT103 sent directly from the ordering bank to the beneficiary bank. The second is the cover, an MT202 COV that moves the funds through the correspondent chain. In the BNPP example a French company, customer of BNP Paribas Paris, BNPAFRPP, sends USD 367,574.90 to a Spanish company, customer of Banco Santander Madrid, BSCHESMM, account ES6300491800132710387658. BNPP sends the MT103 announcement directly to Santander. That message carries fields 53a and 54a, naming Wells Fargo, PNBPUS3N, as the bank that will provide the funds, and Bank of New York Mellon, IRVTUS3N, as Santander's correspondent. It does not move any funds. Separately, BNPP sends an MT202 COV to Wells Fargo, instructing it to move the funds to BNY. Wells Fargo sends a second MT202 COV to BNY, and BNY credits Santander's account. BNY then sends an MT910 to Santander to confirm the credit. Santander reconciles the MT103 announcement with the MT910 confirmation and credits the Spanish company. The announcement and the cover travel on different paths and can arrive at different times, but they carry the same UETR and the same reference 103REF405775, so Santander can match them. That separation of instruction and funding is the whole idea of the cover method.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The MT103 announcement and the MT202 COV cover are two halves of one cover payment, and they do opposite jobs. The announcement is an MT103 sent directly from the ordering bank to the beneficiary bank. In the BNPP example it goes from BNPP to Santander. It carries the full customer payment details, the ordering customer in field 50, the beneficiary account ES6300491800132710387658 in field 59, the instructed amount USD 367,574.90 in field 33B, and the remittance information in field 70. It also carries fields 53a and 54a, which explain how the funds will arrive. It does not move any money. The cover is an MT202 COV, a bank to bank payment message that moves the funds through the correspondent chain. The first cover goes from BNPP to Wells Fargo, and the second goes from Wells Fargo to Bank of New York Mellon. The cover carries no customer details in its main sequence. Instead it has two sequences, A for the transmission details and B for the underlying MT103 details, so the banks moving the funds can see whose payment they are covering without seeing the full customer instruction. The announcement tells the beneficiary bank what is coming. The cover brings the money. Santander must match the two before it credits the customer, unless its risk policy allows it to credit on the announcement alone. If only the announcement arrives, Santander knows about the payment but has no funds. If only the cover arrives, Santander has the funds but may not know which customer they belong to.

Sequence A of an MT202 COV is the general information sequence, and it carries the transmission details of the cover payment itself. It starts with field 20, the transaction reference number of the cover, which is chosen by the bank sending the cover. In the BNPP example the second cover, from Wells Fargo to Bank of New York Mellon, carries field 20 with the value 202PNBPREF2679. Sequence A then carries field 21, the related reference, which links the cover back to the underlying customer payment. In the first cover, from BNPP to Wells Fargo, field 21 carries 103REF405775, the reference of the MT103 announcement. Sequence A also carries field 32A, the value date, currency and interbank settled amount of the cover, and field 52a, the ordering institution, when the bank sending the cover is not the original ordering institution. It can also carry field 53a, the sender's correspondent, field 54a, the receiver's correspondent, field 56a, the intermediary institution, field 57a, the account with institution, field 58a, the beneficiary institution, and field 72, sender to receiver information. The purpose of Sequence A is to tell the receiving bank how to move the funds for this cover step, who sent it, who should receive it, and which underlying payment it belongs to. It does not carry the customer details. Those live in Sequence B, so that the banks moving the funds do not need to process customer data they do not need.

Sequence B of an MT202 COV is the underlying transaction details sequence, and it carries a copy of the key fields from the MT103 announcement so that every bank moving the cover can verify that it is funding the right customer payment. It starts with field 50a, the ordering customer, followed by field 52a, the ordering institution, field 56a, the intermediary institution, field 57a, the account with institution, field 59a, the beneficiary customer, field 70, the remittance information, and field 33B, the currency and instructed amount. In the BNPP example Sequence B of each cover carries the French ordering customer, the beneficiary account ES6300491800132710387658, and the instructed amount USD 367,574.90, exactly as they appear on the MT103 announcement. Sequence B must match the MT103 exactly because it is the control that prevents a cover from being used to fund the wrong payment. If the beneficiary account in Sequence B differs from the beneficiary account in the MT103, the cover and the announcement do not belong together, and the receiving bank must stop and investigate. A mismatch can mean a data entry error, a cover sent against the wrong announcement, or in the worst case an attempt to divert funds. SWIFT validation checks the structure of Sequence B, but the business matching is done by the banks themselves. Operations teams compare Sequence B field by field with the MT103 before they release the funds, and they never release a cover whose Sequence B does not match the announcement it claims to fund.

Tag 119 in Block 3 is the validation flag, and it is what turns an ordinary MT202 into an MT202 COV, a cover payment. Block 3 is the user header, and tag 119 carries a three character code that tells SWIFT and the receiver how the message should be validated. For a cover payment the value is COV, written as {119:COV} inside Block 3. Without tag 119, an MT202 is a plain bank to bank transfer, and the receiver treats it as a payment between banks with no underlying customer payment. With tag 119 set to COV, the receiver knows the message is a cover for an MT103 customer payment, and it must expect a matching announcement with the same UETR and the same underlying details in Sequence B. The flag also triggers extra validation. SWIFT checks that the MT202 COV carries both Sequence A and Sequence B, and that Sequence B is present and correctly formatted. If tag 119 is missing from a message that was meant to be a cover, the receiving bank may process it as a plain MT202 and credit its own account without linking it to the customer payment, which leaves the MT103 announcement unmatched and the beneficiary unpaid. If tag 119 is present on a message that is not a cover, the receiver will look for an announcement that does not exist and hold the funds. The lesson is that tag 119 is small but decisive. Always check Block 3 before processing an MT202, because the flag determines the whole handling of the message.

The UETR, the Unique End to end Transaction Reference, must be identical in the MT103 announcement and the MT202 COV cover because it is the single key that links the two messages together as one payment. The UETR is a 36 character identifier in the format of a universal unique identifier, for example 123e4567-e89b-12d3-a456-426614174000, and it is carried in Block 3 under tag 121. It is created by the ordering bank, BNPP in this course, when the payment is first instructed, and it never changes as the payment moves through the chain. The announcement carries it, the first cover carries it, and the second cover carries it, so every system that sees any part of the payment can recognise it as the same transaction. If the UETR differed between the announcement and the cover, Santander would receive two messages that look like two separate payments. It might credit the beneficiary twice, or it might credit once and leave the other message unmatched, which creates a reconciliation break and a risk of duplicate payment. SWIFT gpi tracking also depends on the UETR. The tracker follows the UETR from bank to bank and shows the customer where the payment is. A changed UETR breaks the tracking chain and the payment disappears from the tracker. The rule is absolute. The UETR is created once, copied exactly, and never regenerated by an intermediary bank. Any system that creates a new UETR for a cover is breaking the payment.

Wells Fargo, BIC PNBPUS3N, plays two roles in the BNPP cover payment example, one in the announcement and one in the cover chain. In the MT103 announcement from BNPP to Santander, Wells Fargo appears in field 53A as the sender's correspondent. That tells Santander that BNPP will provide the funds through Wells Fargo, so Santander knows where the money is coming from even before it arrives. In the cover chain, Wells Fargo is the first correspondent that actually moves the funds. BNPP sends the first MT202 COV to Wells Fargo, instructing it to debit BNPP's US dollar account and to move the funds onward to Bank of New York Mellon. Wells Fargo then sends the second MT202 COV to BNY. Wells Fargo is BNPP's US dollar correspondent, which means BNPP holds a US dollar nostro account with Wells Fargo, and Wells Fargo holds a vostro account for BNPP. That account relationship is what makes the cover work. BNPP cannot pay BNY directly because it holds no account with BNY, so it uses the account it holds with Wells Fargo, and Wells Fargo uses the account it holds with BNY. Wells Fargo may deduct a charge for this service, and it must preserve the UETR and the underlying details in Sequence B so that BNY and Santander can match the cover to the announcement. Without Wells Fargo, BNPP would have no route to move US dollars to Santander's correspondent.

Bank of New York Mellon, BIC IRVTUS3N, plays two roles in the BNPP cover payment example, one in the announcement and one in the cover chain. In the MT103 announcement from BNPP to Santander, BNY appears in field 54A as the receiver's correspondent. That tells Santander that its US dollar account is held at BNY, and that the funds will arrive there. In the cover chain, BNY is the final correspondent before the beneficiary bank. Wells Fargo sends the second MT202 COV to BNY, instructing it to receive the funds and to credit Santander's account. BNY holds a US dollar account for Santander, so when the cover arrives BNY debits Wells Fargo's account and credits Santander's account. BNY then sends an MT910 to Santander to confirm that the credit has been made. That MT910 is the signal Santander waits for before it credits the Spanish company, unless it has already credited on the announcement alone. BNY may deduct a charge of USD 22 for its service, which is recorded in the payment chain and reduces the final amount. BNY must also preserve the UETR and check that Sequence B of the cover matches the MT103 announcement, so that the funds are linked to the right customer payment. Without BNY, Santander would have no US dollar account in the chain, and the funds would have no place to land before they reach the beneficiary bank.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The first MT202 COV in the BNPP cover payment is sent by BNP Paribas Paris, BNPAFRPP, to Wells Fargo, PNBPUS3N. Its Block 3 carries tag 119 with the value COV, marking it as a cover, and tag 121 carrying the UETR, which is identical to the UETR on the MT103 announcement. Sequence A carries field 20, the transaction reference of the cover chosen by BNPP, and field 21, the related reference, which carries 103REF405775, the reference of the MT103 announcement. That link is what ties the cover to the announcement. Sequence A also carries field 32A with the value date, USD, and the settled amount, field 57A naming BNY as the account with institution, and field 58A naming Santander as the beneficiary institution. Sequence B carries the underlying MT103 details, including field 50 for the French ordering customer, field 59 for the beneficiary account ES6300491800132710387658 and the Spanish company, field 70 for the remittance information, and field 33B for the instructed amount USD 367,574.90. The message instructs Wells Fargo to debit BNPP's US dollar account and to move the funds onward to BNY. It does not carry any customer payment instruction of its own. Its only job is to fund the MT103 announcement that BNPP already sent directly to Santander. Wells Fargo, on receipt, checks Sequence B against the announcement details, preserves the UETR, and creates the second MT202 COV to BNY.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The second MT202 COV in the BNPP cover payment is sent by Wells Fargo, PNBPUS3N, to Bank of New York Mellon, IRVTUS3N. Its Block 3 carries tag 119 with the value COV and tag 121 with the same UETR as the MT103 announcement and the first cover. Sequence A carries field 20 with the value 202PNBPREF2679, the transaction reference Wells Fargo chose for this cover, and field 21 with the related reference linking it back to the underlying payment. Sequence A also carries field 52A with BNPAFRPP, and that field is present for an important reason. Wells Fargo is the sender of this cover, but it is not the original ordering institution. BNPP is. Without field 52A, BNY would assume Wells Fargo ordered the payment. With :52A:BNPAFRPP, BNY knows the original order came from BNPP and that Wells Fargo is only passing the cover forward. Sequence A also carries field 32A with the value date, USD, and the settled amount after any Wells Fargo charge, and field 58A naming Santander as the beneficiary institution. Sequence B carries the underlying MT103 details unchanged, including field 50 for the French ordering customer, field 59 for the beneficiary account ES6300491800132710387658, and field 33B for USD 367,574.90. The message instructs BNY to debit Wells Fargo's account and to credit Santander's account. Field 52A preserves the origin of the payment, just as it does in the second and third MT103s of a serial payment.

Field 57A is absent from the second MT202 COV in the BNPP cover payment because the receiver of that cover, Bank of New York Mellon, already holds the account that needs to be credited, so there is no next institution to name. Field 57a, the Account With Institution, always names the institution after the receiver, the place where the next account in the chain is held. In the first MT202 COV, from BNPP to Wells Fargo, field 57A names BNY, because after Wells Fargo the funds must go to BNY. In the second MT202 COV, from Wells Fargo to BNY, the funds have reached BNY, and BNY holds Santander's US dollar account. The next step is for BNY to credit Santander's account directly, not to send the funds to another bank. There is therefore no account with institution beyond BNY, and field 57A is omitted. The same logic explains why field 57A disappears from the third MT103 in a serial payment. When the receiver is the bank that holds the account to be credited, the field has nothing to say. The absence of field 57A is a useful check for operations teams. If it is present, the payment still has another bank to pass through. If it is absent and the receiver holds the beneficiary bank's account, the payment has reached the last correspondent and the next step is a credit to the beneficiary bank, confirmed by an MT910. A cover that wrongly includes field 57A could send funds to the wrong bank, so its absence here is correct, not an error.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The announcement almost always arrives before the cover in a cover payment, because the announcement travels directly from the ordering bank to the beneficiary bank while the cover travels step by step through the correspondent chain. But the cover can arrive first, and payment software must handle that case. If Bank of New York Mellon credits Santander's account and sends the MT910 before Santander has received the MT103 announcement from BNPP, Santander has the funds but does not yet know which customer they belong to. The funds sit in Santander's account at BNY, and Santander's system must hold them as unallocated until the announcement arrives. It must not guess the beneficiary from the cover alone, because the cover's Sequence B does carry the beneficiary details, but the full customer instruction, including the remittance information and the ordering customer details, lives on the announcement. The correct handling is to match on the UETR. When the announcement arrives, Santander compares its UETR with the UETR on the cover and on the MT910, and if they match, it credits the beneficiary account ES6300491800132710387658. Good payment systems keep unmatched covers in a queue and match them automatically when the announcement arrives. Poor systems reject the cover or hold it manually, which delays the payment. The lesson for operations teams is to never assume the order of arrival. Design for either order, match on the UETR, and never credit a customer from a cover alone without a matching announcement or a clear policy that allows it.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. The beneficiary bank can credit the customer on the MT103 announcement alone, before the cover funds arrive, but only when its risk policy allows it and the conditions are right. The announcement tells Santander that BNPP has instructed a payment of USD 367,574.90 to the Spanish company, account ES6300491800132710387658, and that the funds will arrive through Wells Fargo and Bank of New York Mellon. If Santander trusts BNPP, if the amount is within the threshold its policy sets for early credit, if the relationship with BNPP is strong, and if the beneficiary is a known customer with a clean compliance record, Santander may credit the Spanish company immediately and wait for the cover to reimburse its account. That is called crediting on the announcement, and it is one of the main speed advantages of the cover method. The bank takes a risk when it does this. If the cover never arrives, or if it arrives for a smaller amount because of charges, Santander has paid out funds it has not yet received. That is why early credit is never automatic. It depends on trust, on the amount, on the corridor, and on the bank's own liquidity. Large amounts, new correspondents, high risk countries, and customers with compliance flags are never credited early. The decision is made by the bank's policy, not by the customer, and the customer cannot demand early credit. When Santander does credit early, it still reconciles the announcement with the MT910 when the cover arrives, and any difference in amount is handled as a charge or a short payment.

In a cover payment the MT910 is the confirmation that the beneficiary bank's account has been credited, and it is the message that lets the beneficiary bank reconcile the announcement with the funds. In the BNPP example Bank of New York Mellon sends an MT910 to Santander after it credits Santander's US dollar account. The MT910 carries field 20, the transaction reference, field 21, the related reference linking it to the cover, field 25, the account number credited, field 32A, the value date, currency and amount, and field 52a, the ordering institution. The MT910 is itself a cover in the sense that it confirms the cover funds have arrived. Santander matches the MT910 against the MT103 announcement it received directly from BNPP, and when the amounts and references align, it credits the Spanish company. The MT910 cannot carry a UETR, and the reason is a standard limitation. Field 72 of an MT910 cannot carry a UETR under the SWIFT standard, and there is no Block 3 tag defined for a UETR on an MT910. That means Santander cannot match the MT910 to the announcement by UETR alone. It must match by reference, account, amount and value date, which is slower and more error prone. The workaround is to convert the MT910 into an MT199 or MT299 free format message that can carry the UETR in its text, so that the gpi tracker can follow the payment. The alternative is to use an MT950 statement instead of an MT910, because the statement can be reconciled against the UETR through the bank's own systems.

A bank that needs to confirm a cover payment can use an MT910 or an MT950, and the choice depends on whether it needs a single confirmation or a full statement. An MT910 is a Confirmation of Credit. It is sent for one specific credit, it arrives promptly after the credit is posted, and it carries the reference, the account, the value date and the amount for that one movement. In the BNPP example BNY sends an MT910 to Santander for the single credit of the cover funds, so Santander knows immediately that the money has arrived and can credit the Spanish company. An MT950 is a Statement Message. It is sent at the end of the day or at an agreed frequency, and it lists every movement on the account in that period, with opening and closing balances. It confirms the same credit, but only when the statement is produced, which may be hours later. The MT910 is better when speed matters, because it triggers the beneficiary credit without waiting for the statement. The MT950 is better when the bank wants a complete, balanced record that it can reconcile in full, because it shows the credit in context with every other movement and the closing balance. Many banks use both. They act on the MT910 to credit the customer promptly, and they reconcile against the MT950 at the end of the day to confirm that the MT910 credit appears on the statement and that the closing balance is correct. If only one can be used, the MT910 is the right choice for a cover confirmation, because the MT950 arrives too late to drive a same day customer credit.

An MT202 and an MT202 COV look similar, but they are different messages with different purposes, and the difference is marked in Block 3. A plain MT202 is a General Financial Institution Transfer. It moves funds from one bank to another for the banks' own business, for example to settle a trade, to fund a nostro account, or to repay a loan between banks. It has a single sequence, it carries no customer payment details, and it needs no matching MT103. An MT202 COV is a cover payment. It moves funds through the correspondent chain to fund a specific MT103 customer payment, and it is marked by tag 119 with the value COV in Block 3. It has two sequences. Sequence A carries the transmission details of the cover itself, and Sequence B carries the underlying MT103 details, including the ordering customer, the beneficiary, and the instructed amount, which must match the announcement exactly. The UETR on an MT202 COV is identical to the UETR on the MT103 it covers, while a plain MT202 has its own UETR or none at all. The handling is also different. A bank that receives a plain MT202 credits its own account, which settles the bank-to-bank leg; the beneficiary bank must still credit the customer; the payment is only complete for the customer once that credit is posted. A bank that receives an MT202 COV must match it to the MT103 announcement before it releases the funds to the beneficiary bank. Confusing the two is a serious error. Treating a cover as a plain transfer can leave a customer payment unfunded, and treating a plain transfer as a cover can hold bank funds while the operations team searches for an announcement that does not exist.

MT200 is the Financial Institution Transfer for its Own Account message. It is used when a bank moves its own funds from one of its accounts to another of its accounts held at a different bank. For example, BNP Paribas Paris might use an MT200 to move US dollars from its account at Wells Fargo to its account at Bank of New York Mellon, to balance its liquidity or to fund a payment it expects to make later in the day. The message is simple. It carries field 20, the transaction reference, field 32A, the value date, currency and amount, field 53a, the sender's correspondent if needed, field 54a, the receiver's correspondent if needed, and field 57a, the account with institution. It carries no customer details, because there is no customer. The funds belong to the bank itself. MT200 is different from MT202, which is a general transfer between two different financial institutions, and different from MT202 COV, which funds a customer payment. MT200 is also different from MT103, which always involves a customer. Operations teams use MT200 for liquidity management, for funding nostro accounts before a busy payment day, and for moving funds after a large receipt. Because it is the bank's own money, the compliance checks are lighter than on a customer payment, but the reconciliation is just as strict. The sending bank must confirm the debit to its nostro account, and the receiving bank must confirm the credit, usually through an MT900 or MT910 or through the next MT950 statement.

MT203 is the Multiple Financial Institution Transfer message. It is used when a bank wants to send several bank to bank transfers to the same receiver in a single message, instead of sending a separate MT202 for each one. For example, Wells Fargo might owe Bank of New York Mellon three separate amounts in US dollars on the same day, for three different internal purposes, and it can combine them into one MT203 with three separate transfer details. The message carries field 20, the transaction reference, field 23, a code that confirms it is a multiple transfer, field 32A, the value date, currency and total amount of all the transfers combined, and then a repeating set of fields for each individual transfer, including the amount, the ordering institution, and the beneficiary institution for that transfer. The total in field 32A must equal the sum of the individual transfers, and the receiver reconciles each one separately. MT203 saves message traffic and reduces SWIFT charges, because one message replaces several, but it also creates a single point of failure. If one transfer in the MT203 is wrong, the whole message may need to be investigated, and the receiver cannot easily reject one transfer without holding the others. For that reason MT203 is used mainly between banks with a strong relationship and a high volume of transfers, and it is never used for customer payments. Customer payments always used MT103 before the CBPR+ migration, and a cover for a customer payment always used MT202 COV, not MT203. Since coexistence ended on 22 November 2025, the same rule applies in ISO 20022: the customer leg is a pacs.008 and the cover is a pacs.009 COV.

MT210 is the Notice to Receive message. It is used by a bank to tell another bank that it should expect to receive funds on a given value date, even though the funds have not yet arrived. For example, BNP Paribas might send an MT210 to Wells Fargo to say that it expects to receive USD 500,000 on 5 January 2026 from a third bank, so that Wells Fargo can plan its liquidity and watch for the incoming credit. The message carries field 20, the transaction reference, field 21, the related reference, field 25, the account to be credited, field 30, the value date, field 32B, the currency and amount expected, and field 50, the ordering customer or institution. A notice to receive is not a payment instruction. It does not move any funds, and the receiver takes no action on it except to expect the funds and to match them when they arrive. It is a planning and reconciliation tool. Treasury teams use MT210 to forecast their nostro balances, to make sure they have enough liquidity for the payments they need to make, and to detect a missing receipt quickly. If the expected funds do not arrive on the value date, the MT210 gives the receiver a reference to chase, and it can send an MT199 to ask where the funds are. Without an MT210, a bank only discovers a missing receipt when it reconciles its statement at the end of the day, which may be too late to fix the problem the same day.

A bank should use MT202 instead of MT103 when the payment is between two financial institutions and there is no customer ordering or receiving the payment. An MT103 is a Single Customer Credit Transfer. It always has an ordering customer in field 50 and a beneficiary customer in field 59, and it is used when a person or a company sends money to another person or company. An MT202 is a General Financial Institution Transfer. It has no customer fields, and it is used when one bank pays another bank for the banks' own business. Examples include settling a foreign exchange trade, repaying an interbank loan, funding a nostro account, paying a fee to another bank, or settling a securities transaction. In the BNPP example the customer payment from the French company to the Spanish company uses MT103, because there are customers at both ends. The funding of that payment through the correspondent chain uses MT202 COV, because the banks are moving funds between themselves to cover the customer payment. A bank should never use MT202 to pay a customer directly, because the receiver would have no beneficiary details and no way to credit the right account. It should never use MT103 for a bank to bank settlement, because the customer fields would be misleading and the compliance screening would be wrong. The test is simple. If there is a customer at either end, use MT103. If both ends are banks acting for themselves, use MT202.

No, an MT202 cannot be used to pay a customer directly, and a bank that tries to do so will leave the beneficiary unpaid. An MT202 is a bank to bank transfer. It carries no ordering customer field and no beneficiary customer field, so the receiving bank has no customer account to credit and no customer name to check. If BNPP sent an MT202 to Santander with the intention of paying the Spanish company, Santander would receive funds into its own account at Bank of New York Mellon, but it would have no instruction telling it which customer account to credit, no beneficiary account number, and no remittance information. The funds would sit in Santander's nostro account as an unallocated receipt, and the Spanish company would never be paid. The correct message for a customer payment is always MT103, which carries field 50 for the ordering customer, field 59 for the beneficiary customer and account ES6300491800132710387658, field 70 for the remittance information, and field 33B for the instructed amount. The MT202 COV is the one exception that looks like a customer payment, because its Sequence B carries the customer details, but even there the MT202 COV does not pay the customer. It funds the MT103 announcement, and the beneficiary bank credits the customer from the announcement, not from the cover. Any payment instruction that names a customer must travel as an MT103, and any MT202 that arrives without a matching MT103 should be treated as a bank to bank movement, not as a customer payment.

An MT202 COV differs from a plain MT202 in three ways: its Block 3 flag, its two sequences, and its UETR. A plain MT202 has a single sequence that carries the bank to bank transfer details, field 20 for the reference, field 21 for the related reference, field 32A for the value date and amount, and the correspondent fields that route the funds. It has no Sequence B and no customer data. An MT202 COV carries tag 119 with the value COV in Block 3, which marks it as a cover payment and triggers extra validation. It has two sequences. Sequence A carries the transmission details of the cover itself, including field 20, field 21 with the MT103 reference 103REF405775, field 32A, and field 52a when the sender is not the ordering institution. Sequence B carries the underlying MT103 details, including field 50 for the ordering customer, field 59 for the beneficiary account ES6300491800132710387658, field 70 for the remittance information, and field 33B for the instructed amount USD 367,574.90. Sequence B must match the MT103 announcement exactly. The UETR is also different. A plain MT202 has its own UETR or none, because it is a standalone bank payment. An MT202 COV carries the same UETR as the MT103 it covers, in Block 3 tag 121, so that every system can link the cover to the announcement. Without these differences the receiver cannot tell a cover from a plain transfer, and the customer payment it funds would never be matched.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If an MT202 COV arrives without a matching MT103 announcement, the receiving bank has funds it cannot link to a customer payment, and it must hold the funds and investigate. Suppose Bank of New York Mellon receives the second cover from Wells Fargo, but Santander has not received the MT103 announcement from BNPP, perhaps because the announcement was delayed, rejected by validation, or sent to the wrong BIC. BNY can credit Santander's account, because the cover itself is a valid bank to bank instruction, but Santander receives the funds without knowing which customer they belong to. Santander's system should place the cover in an unmatched queue, keyed by its UETR and by the reference 103REF405775 in field 21, and wait for the announcement to arrive. It should not guess the beneficiary from Sequence B alone, because Sequence B is a summary, not the full customer instruction, and crediting from it without the announcement can cause errors. If the announcement never arrives, Santander must send an MT199 to BNPP asking for the announcement, or to Wells Fargo asking for the underlying details, and it must keep the funds unallocated until the reply arrives. If the announcement arrives later, Santander matches it by UETR, confirms that Sequence B matches the announcement field by field, and credits the beneficiary. The cover first case is the mirror image of the announcement first case, and good payment systems handle both orders by matching on the UETR rather than on arrival time.

MT200, MT202 and MT203 are three messages in the same family, the category 2 financial institution transfers, and they differ by who the funds belong to and how many transfers are combined. MT200 is a transfer for a bank's own account. The sender and the owner of the funds are the same bank, and the message moves the bank's own money from one of its accounts to another. MT202 is a general transfer between two different financial institutions. The sender pays the receiver for the banks' own business, such as settling a trade or funding an account, and there is no customer involved. MT203 is a multiple transfer. It combines several MT202 style transfers to the same receiver into one message, with a total amount in field 32A and a repeating set of details for each individual transfer. The relationship is one of scope. MT200 is the narrowest, one bank moving its own funds. MT202 is the general case, one bank paying another bank. MT203 is the bulk case, several bank to bank transfers in one message. None of the three is a customer payment, and none of them carries customer fields. Customer payments always use MT103, and a cover for a customer payment always uses MT202 COV, which is a special form of MT202 with tag 119 and two sequences. When you see a category 2 message, the first question to ask is whose funds they are. If they belong to the sending bank itself, it is MT200. If they belong to another bank, it is MT202. If there are several transfers in one message, it is MT203.

Before releasing funds on an MT202, an operations analyst should check five things. First, check Block 3 for tag 119. If it carries COV, the message is a cover for a customer payment, and it must have two sequences and a matching MT103 announcement. If tag 119 is absent, it is a plain bank to bank transfer and no announcement is expected. Second, check field 20 and field 21. Field 20 is the reference of this cover, and field 21 is the related reference that links it to the underlying payment, such as 103REF405775 in the BNPP example. A missing or wrong related reference means the cover cannot be matched. Third, check field 32A, the value date, currency and settled amount, and confirm that the amount matches what the sender is expected to pay and that the value date is not in the past. Fourth, check field 52a, the ordering institution, and confirm that it names the true originator, such as BNPAFRPP, when the sender is only an intermediary. Fifth, if it is an MT202 COV, check Sequence B field by field against the MT103 announcement, including field 50 for the ordering customer, field 59 for the beneficiary account ES6300491800132710387658, and field 33B for the instructed amount USD 367,574.90. Any mismatch in Sequence B means the cover and the announcement do not belong together, and the funds must be held. Only when all five checks pass should the funds be released. A single missed check can send bank funds to the wrong account.

MT900 and MT910 are a pair of confirmation messages, and they differ only by the direction of the movement they confirm. MT900 is a Confirmation of Debit. It is sent by an account servicing bank to an account owner to confirm that an amount has been debited from the owner's account. For example, if Wells Fargo debits BNPP's US dollar account to fund the cover payment, Wells Fargo sends an MT900 to BNPP confirming the debit. MT910 is a Confirmation of Credit. It is sent by an account servicing bank to an account owner to confirm that an amount has been credited to the owner's account. In the BNPP example Bank of New York Mellon sends an MT910 to Santander after it credits Santander's US dollar account with the cover funds. Both messages carry field 20 for the transaction reference, field 21 for the related reference, field 25 for the account number, field 32A for the value date, currency and amount, and field 52a for the ordering institution. The difference is the accounting direction. MT900 means money left your account. MT910 means money arrived in your account. Operations teams use them as real time confirmations that a specific movement has posted, without waiting for the end of day statement. A bank that receives an MT900 it did not expect should investigate immediately, because it means funds have left its account. A bank that receives an MT910 should match it to the payment it was expecting, in the BNPP case the MT103 announcement, before it credits its customer.

MT940 and MT950 are both statement messages, and they differ by who the account owner is. MT940 is a Customer Statement Message. It is sent by a bank to its customer, which may be a company or another bank acting as a customer, and it lists all the movements on the customer's account in a given period, with opening and closing balances. MT950 is a Statement Message. It is sent by an account servicing bank to another financial institution that holds an account with it, and it lists all the movements on that institution's account. In practice the two messages have almost the same structure. Both carry field 20 for the statement reference, field 25 for the account number, field 28C for the statement number and sequence, field 60 for the opening balance, a repeating set of fields 61 and 86 for each transaction, and field 62 for the closing balance. The difference is the audience and the use. MT940 is the statement a corporate treasurer reconciles every morning to see what has hit the company's account. MT950 is the statement a bank reconciles to see what has hit its nostro account at another bank. In the BNPP example Santander receives an MT950 from Bank of New York Mellon showing the credit of the cover funds, and BNPP receives an MT950 from Wells Fargo showing the debit. A bank that reconciles nostro accounts works with MT950 every day. A corporate that reconciles its own bank account works with MT940. The content is the same. The relationship is different.

MT941 is a Balance Report message. It is sent by an account servicing bank to an account owner to report the balance of an account at a specific point in time, without listing the individual transactions. It carries field 20 for the transaction reference, field 21 for the related reference, field 25 for the account number, field 28C for the statement number, and field 62 for the closing balance, plus optional fields for the available balance and the forward balance. A balance report is used when the account owner needs to know how much is in the account right now, but does not need the full statement. The most common use is intraday liquidity management. A treasurer at BNPP might request an MT941 from Wells Fargo in the middle of the day to check whether its US dollar account holds enough to fund the next cover payment, before it sends the MT202 COV. Another use is a cut off check. A bank that is about to close its books asks for an MT941 to confirm the balance it should carry forward. MT941 is different from MT940 and MT950, which list every transaction, and different from MT942, which lists transactions since the last statement. MT941 answers one question only, what is the balance. It is fast, it is light, and it is often sent on request rather than on a schedule. If the balance on an MT941 does not match the balance the account owner expects, the next step is to request an MT942 or an MT940 to see which transactions explain the difference.

MT942 is an Interim Transaction Report message. It is sent by an account servicing bank to an account owner to report the transactions that have posted to an account since the last statement, without waiting for the next full statement. It carries field 20 for the transaction reference, field 25 for the account number, field 28C for the statement number, field 34F for the floor limit indicator, and a repeating set of fields 61 and 86 for each transaction, plus field 62 for the closing balance at the time of the report. An interim report is used when the account owner needs to see movements intraday, for example to confirm that a cover payment has been credited before the end of day statement is produced. In the BNPP example Santander could receive an MT942 from Bank of New York Mellon during the day showing the credit of the cover funds, and credit the Spanish company without waiting for the MT950 statement that evening. MT942 is different from MT941, which reports only the balance and no transactions, and different from MT940 and MT950, which are full statements for a complete period. MT942 is also different from MT910, which confirms a single credit. MT942 can list several transactions, and it is often sent automatically when the account balance crosses a threshold or when a large transaction posts. Treasury and operations teams use MT942 to monitor nostro accounts in real time, to catch a missing receipt early, and to reconcile a payment the same day instead of the next morning.

Field 25 is the Account Identification field in SWIFT statement and confirmation messages, including MT900, MT910, MT940, MT942 and MT950. It is mandatory and it carries the number of the account to which the message relates, for example :25:US1234567890 or, for the BNPP example, the US dollar account Santander holds at Bank of New York Mellon. The account number must match exactly the account number the account owner holds in its own records, including any leading zeros, branch codes, or currency suffixes, because it is the key that the receiving system uses to post the statement to the right account. If field 25 is wrong, the statement is posted to the wrong account, or it is rejected as unrecognised, and the reconciliation breaks. That is especially dangerous on an MT910, where a wrong account number could lead the receiver to think a different account was credited. Field 25 is also used to match a confirmation to a payment. When Santander receives an MT910 from BNY, it checks field 25 to confirm that the credit landed in the account it expected, and it checks field 32A to confirm the amount and value date. If field 25 does not match, Santander must not credit the customer until the discrepancy is resolved. The practical rule is to never edit field 25, never truncate it, and never assume two accounts with similar numbers are the same. Statement automation depends on an exact match, and a single wrong digit can hold up the reconciliation of a whole day's payments.

Fields 60 and 62 are the balance fields in SWIFT statement messages, MT940 and MT950, and they frame every statement so that it can be proved complete. Field 60 is the Opening Balance. It is mandatory and it carries the balance of the account at the start of the statement period, with a debit or credit marker, the value date, the currency, and the amount, for example :60F:C260104USD1000000,00, meaning a credit balance of USD 1,000,000 on 4 January 2026. Field 62 is the Closing Balance. It is mandatory and it carries the balance at the end of the statement period in the same format, for example :62F:C260105USD1367532,90. Between them sit the individual transactions in fields 61 and 86. The arithmetic must balance exactly. The opening balance plus all credits minus all debits in the statement must equal the closing balance. If the BNPP cover credit of USD 367,532.90 appears as a transaction, the closing balance must be USD 367,532.90 higher than it would have been without it. Field 60M and field 62M are the intermediate opening and closing balances used when a statement is split across several messages. The practical use is reconciliation. The account owner takes the closing balance from the previous statement, checks that it equals the opening balance on the new statement, adds the transactions, and checks that the result equals the new closing balance. If any step fails, a transaction is missing or duplicated, and the reconciliation team must investigate before the books are closed.

Field 86 is the Information to Account Owner field in SWIFT statement messages, MT940, MT942 and MT950. It is optional, it follows each field 61 transaction line, and it carries the narrative that explains what that transaction was, so that the account owner can identify it without looking up the original payment message. Its format is up to six lines of 65 characters, and it can carry structured codes or free text, depending on the agreement between the account servicing bank and the account owner. A typical field 86 for the BNPP cover credit might read: MT103, reference 103REF405775, ordering customer the French company, beneficiary account ES6300491800132710387658, instructed amount USD 367,574.90, charges USD 42. That single field lets Santander's reconciliation team match the statement line to the MT103 announcement and the MT910 confirmation without opening any other system. Field 86 can also carry the SWIFT message type, the transaction reference, the ordering and beneficiary details, and any charges deducted. The quality of field 86 varies by bank. Some banks send rich, structured data that reconciles automatically. Others send a short code that needs manual interpretation. When field 86 is vague or missing, reconciliation slows down, because the team must search by amount and value date alone, and two payments for the same amount on the same day become hard to tell apart. Good practice is to agree the field 86 format with each correspondent in advance, and to include the reference, the UETR where possible, and the underlying MT103 reference on every line.

An MT940 statement reconciles with the MT103 and MT202 payments it lists by matching each statement line to the original payment message using the reference, the amount, the value date and the account. Each transaction on the statement appears as a field 61 line, which carries the value date, the debit or credit marker, the amount, the transaction type, and the reference, followed by a field 86 line that carries the narrative, including the MT103 reference such as 103REF405775. The reconciliation team takes the MT103 announcement and the MT202 COV cover for the BNPP payment and checks that a matching field 61 line appears on the MT940 for the same value date, the same currency, and the same amount, USD 367,532.90 for the final credit to Santander. It also checks that the opening balance in field 60 plus all the credits minus all the debits equals the closing balance in field 62, which proves no transaction is missing or duplicated. If a payment appears on the MT103 but not on the MT940, the funds have not yet posted, or the statement period ended before the credit arrived. If a payment appears on the MT940 but has no matching MT103, it is an unallocated receipt that must be investigated, because it may belong to another payment or it may be a duplicate. Automated reconciliation systems match on reference first, then on amount and value date. Manual reconciliation is needed only when the reference is missing or when two payments share the same amount. The MT940 is the proof that the payments actually posted.

A bank uses MT900 and MT910 messages to reconcile nostro account movements in real time, without waiting for the end of day statement. Each MT900 confirms a single debit from the bank's account, and each MT910 confirms a single credit to the bank's account. When BNPP sends the first MT202 COV to Wells Fargo, Wells Fargo debits BNPP's US dollar account and sends an MT900 to BNPP confirming the debit, with field 25 for the account, field 32A for the value date and amount, and field 21 for the related reference 103REF405775. BNPP matches that MT900 against the MT202 COV it sent, confirms the debit posted for the right amount on the right value date, and updates its nostro ledger. When BNY credits Santander's account, it sends an MT910 to Santander, and Santander matches it against the MT103 announcement it received from BNPP, confirms the credit, and releases the funds to the Spanish company. The reconciliation is a three way match. The payment instruction, the MT900 or MT910 confirmation, and the nostro ledger entry must all agree on reference, amount, value date and account. If an MT900 arrives with no matching instruction, the bank must investigate immediately, because funds have left its account without authorisation. If an expected MT910 does not arrive, the bank must chase the correspondent, because the funds may be delayed or stuck. At the end of the day the MT900 and MT910 confirmations are checked again against the MT950 statement, which must list every confirmed movement and no others.

When an MT940 closing balance in field 62 does not match the bank's own ledger, the operations team must stop and investigate before the books are closed, because the difference means a transaction is missing, duplicated, or posted for the wrong amount. The first step is to check the opening balance in field 60 against the closing balance of the previous statement. If they differ, the problem started before this statement, and the previous day must be reopened. The second step is to add up all the field 61 transactions on the statement and confirm that the opening balance plus credits minus debits equals the closing balance in field 62. If that arithmetic fails, the statement itself is incomplete, perhaps because it was split across messages and one part is missing. The third step is to compare each field 61 line with the ledger, matching on reference, amount and value date. Common causes are a payment that posted a day late, so it appears on the next statement, a charge that the ledger did not expect, a duplicate MT910 that caused a double credit, or a payment that was returned and posted as a separate line. In the BNPP example a missing credit of USD 367,532.90 would make the closing balance exactly that amount lower than the ledger expects, which points straight to the cover payment. The team should never force the ledger to match the statement by posting an unexplained adjustment. It should find the transaction, confirm it with the correspondent by MT199 if needed, and post the correction with a clear audit trail. Only when the balances agree can the reconciliation be signed off.

MT190, MT191 and MT192 are three category 1 messages used for charges and cancellations on customer payments, and each has a distinct job. MT190 is an Advice of Charges. It is sent by a bank to tell another bank that charges are due on a payment, for example when Wells Fargo advises BNPP that a USD 20 charge applies to the cover payment it handled. It carries field 20 for the reference, field 21 for the related reference, field 32A for the amount of the charges, and field 71B for the details. MT191 is a Request for Payment of Charges. It is sent by a bank to ask another bank to pay charges that are owed, for example when BNY asks Wells Fargo to pay the USD 22 charge it deducted. It carries the same reference fields plus the amount requested and the account to be debited. MT192 is a Request for Cancellation. It is sent by a bank to ask another bank to cancel a payment instruction it already sent, for example when BNPP discovers the beneficiary account ES6300491800132710387658 was wrong and asks Wells Fargo to stop the MT103 before it is forwarded to BNY. MT192 carries field 20 for its own reference, field 21 for the reference of the message to be cancelled, and field 11S for the original message type and reference. A cancellation is only a request. The receiving bank must confirm whether it could stop the payment in time, and if the funds have already moved, the cancellation becomes a return instead. These three messages keep the commercial side of a payment clean, so that charges and cancellations do not have to be handled by phone or email.

MT195, MT196 and MT199 are three category 1 messages used for queries, answers and free format communication about customer payments. MT195 is a Queries message. It is sent by a bank to ask another bank a question about a payment, for example when Santander asks BNPP why the amount it received is USD 367,532.90 instead of the instructed USD 367,574.90. It carries field 20 for its own reference, field 21 for the related reference of the payment being queried, field 11S for the original message type, and field 75 for the question itself. MT196 is an Answers message. It is sent in reply to an MT195, and it carries the same reference fields plus field 76 for the answer. The pair creates a clear audit trail, because the question and the answer are linked by the related reference and can be traced together. MT199 is a Free Format Message. It is sent when no structured message fits the need, for example to explain a complex exception, to send a narrative update on an investigation, or to carry a UETR that cannot be carried on another message type. In the BNPP cover example, if BNY needs to send Santander a UETR that the MT910 cannot carry, it converts the MT910 into an MT199 and puts the UETR in the free text. MT199 carries field 20, field 21, field 79 for the narrative, and optional field 13D for a date. The rule is to use MT195 and MT196 when the exchange is a simple question and answer, and MT199 when the message is a narrative that does not fit a structured format.

MT290, MT291 and MT292 are the category 2 equivalents of MT190, MT191 and MT192, and they do the same jobs for bank to bank transfers that the MT190 series does for customer payments. MT290 is an Advice of Charges for a financial institution transfer. It tells another bank that charges are due on an MT202 or MT200 payment, for example when Bank of New York Mellon advises Wells Fargo of a charge on the cover it handled. MT291 is a Request for Payment of Charges for a financial institution transfer. It asks another bank to pay charges owed on a bank to bank payment, with the amount, the account, and the related reference. MT292 is a Request for Cancellation for a financial institution transfer. It asks another bank to cancel an MT202, MT200 or MT203 it already sent, for example when Wells Fargo discovers the second MT202 COV was sent with the wrong amount and asks BNY to stop it before it credits Santander. The structure mirrors the MT190 series exactly. Field 20 is the reference of the new message, field 21 is the related reference of the payment, field 11S identifies the original message type and reference, and the charges fields carry the amounts. The reason for the separate series is that category 1 messages relate to customer payments and category 2 messages relate to bank to bank payments, and SWIFT keeps the two categories distinct so that systems can route them to the right team. A charges query about a customer payment goes to the customer payments team as MT190. The same query about a cover payment goes to the bank to bank team as MT290.

MT295, MT296 and MT299 are the category 2 equivalents of MT195, MT196 and MT199, and they handle queries, answers and free format communication about bank to bank transfers. MT295 is a Queries message for a financial institution transfer. It is sent by a bank to ask another bank a question about an MT202, MT200 or MT203, for example when Bank of New York Mellon asks Wells Fargo why the second MT202 COV carries a different value date from the first. It carries field 20 for its own reference, field 21 for the related reference, field 11S for the original message type, and field 75 for the question. MT296 is an Answers message. It is sent in reply to an MT295, with the same reference fields and field 76 for the answer, so that the question and answer stay linked. MT299 is a Free Format Message for a financial institution transfer. It is used when no structured message fits, for example to explain a complex exception on a cover payment, to send a narrative update, or to carry a UETR that cannot be carried on the original message type. In the BNPP cover example, if BNY needs to tell Santander the UETR for a cover whose MT910 cannot carry it, it can send an MT299 with the UETR in the free text, so that Santander can match the cover to the MT103 announcement. The rule mirrors category 1. Use MT295 and MT296 for a structured question and answer, and MT299 for a narrative. Keeping the categories separate matters, because a query about a cover belongs with the bank to bank team, not the customer payments team.

A full payment investigation starts when a payment is missing, short, or stuck, and it uses the investigation messages in a clear order. Take the BNPP payment of USD 367,574.90 to the Spanish company. If Santander has the MT103 announcement but no funds after two days, it first checks its own systems, then sends an MT199 to BNPP asking for the status, quoting the reference 103REF405775 and the UETR. BNPP checks its records and replies by MT199, confirming that it sent the first MT202 COV to Wells Fargo. Santander then sends an MT295 to Wells Fargo, as a category 2 query about the cover, asking whether the second MT202 COV was sent to Bank of New York Mellon. Wells Fargo replies by MT296, confirming the cover was sent with reference 202PNBPREF2679. Santander then sends an MT299 to BNY asking whether the cover was received and whether the MT910 was sent. BNY replies by MT299, confirming the credit and, if the MT910 was lost, resending the details with the UETR in the text. If the investigation shows the payment was sent to the wrong account, the bank that sent it issues an MT192 to cancel the customer payment, or an MT292 to cancel the cover, and the funds are returned step by step. At each stage the related reference and the UETR are quoted, so that every message links to the same payment. The investigation is closed only when the beneficiary confirms receipt or the funds are returned to the ordering customer, and every message is kept as the audit trail.

An RMA, or Relationship Management Application, is the SWIFT authorisation that controls which banks can send which types of messages to each other over the SWIFT network. Before Bank A can send an MT103 payment instruction to Bank B, Bank A must hold an RMA authorisation from Bank B for that message type, and Bank B must hold the matching authorisation in the other direction if it wants to reply. Without an RMA, SWIFT blocks the message at the network level, so it never reaches the receiver. This is a security control, not a commercial agreement. It stops unsolicited messages, reduces fraud, and gives each bank a clear list of who is allowed to instruct it. An RMA is set up per BIC pair and per message category, so a bank can authorise payment messages from a correspondent while refusing other message types. For example, BNP Paribas Paris, BIC BNPAFRPP, and its US dollar correspondent Wells Fargo, BIC PNBPUS3N, must have RMAs in place before Wells Fargo can receive payment instructions from BNP Paribas and before it can return confirmations such as MT910 credit advice. Setting up an RMA is usually a back office task handled through SWIFT Alliance or a similar interface, and it is one of the first steps when a new correspondent relationship goes live. If a payment fails with an RMA error, the operations team must check the authorisation before investigating anything else, because no amount of correct payment data will pass a missing RMA.

A bank chooses a correspondent by matching its payment flows to a partner that can settle them safely, quickly, and at a fair price. The first test is coverage. A French bank sending US dollars needs a correspondent with a US dollar account at the Federal Reserve and a strong US clearing presence, which is why BNP Paribas uses Wells Fargo, BIC PNBPUS3N, for US dollars. The second test is credit and risk. The bank checks the correspondent credit rating, capital strength, regulatory record, and sanctions compliance history, because funds held in a nostro account are an exposure to that bank. The third test is service quality, measured by cut off times, straight through processing rates, the speed of investigations, and the quality of reporting. Price matters too, including account maintenance fees, per transaction charges, and FX spreads, but the cheapest correspondent is rarely the best if it is slow or unreliable. Banks also consider reciprocity, time zone coverage, and whether the correspondent can handle the currencies and corridors the bank needs most. Large banks run a formal request for proposal, score the candidates, and review the relationship every year. Smaller banks often rely on one or two correspondents per currency, while large banks keep several, so they can switch volume if one correspondent has an outage or raises its prices.

Nostro account reconciliation is the daily process of matching every entry on a nostro account statement from the correspondent bank against the bank own internal records, to prove that the two agree. The bank downloads the statement from, say, Wells Fargo for its US dollar nostro account, and compares each debit and credit with its own ledger. Items that match are cleared. Items that do not match become breaks, and each break must be investigated. Common breaks include a payment debited by the correspondent but not yet recorded internally, a charge of USD 20 deducted without a matching instruction, a value date difference, or a credit that arrived a day later than expected. Reconciliation matters because a nostro account is real money held abroad. An unreconciled difference can hide a duplicate payment, a fraud, a misapplied credit, or a liquidity shortfall. Most banks reconcile daily, and many now reconcile intraday for their largest accounts. The process uses the account statement, usually an MT940 or MT950, plus the bank own payment records. Unmatched items are aged, and old breaks are escalated to operations managers because they can affect the bank balance sheet and its regulatory reporting. Good reconciliation also feeds liquidity forecasting, since the reconciled balance is the true amount available for new payments that day.

A nostro overdraft happens when a bank instructs its correspondent to pay out more money from a nostro account than the account actually holds, so the balance goes negative. Because the correspondent has already paid the beneficiary, it has effectively lent the bank money for a short period, usually until the bank sends funds to cover the shortfall. Correspondents normally agree an overdraft limit in advance, as part of the account terms, and they charge interest and fees on any amount drawn. An overdraft can be planned or accidental. A planned overdraft is used when a large payment must go out before incoming funds arrive later the same day. An accidental overdraft happens when several payments are released at once and the liquidity team has not funded the account in time. For example, if BNP Paribas holds USD 300,000 in its Wells Fargo nostro account and releases a USD 367,574.90 payment to Banco Santander in Madrid, the account would go overdrawn by more than USD 67,000 unless funds are sent first. Correspondents dislike unplanned overdrafts because they create credit exposure, so they may reject the payment, delay it, or charge a penalty rate. Banks therefore monitor nostro balances intraday and move funds between accounts before releasing large payments, rather than relying on overdrafts as a routine tool.

A bilateral correspondent arrangement is a direct relationship between two banks, where each holds an account with the other or one holds an account with the other, and they settle payments directly between themselves. For example, BNP Paribas holds a US dollar nostro account with Wells Fargo, and Wells Fargo may hold a euro account with BNP Paribas. When BNP Paribas sends dollars to a customer of Wells Fargo, the payment moves through that one account, and the two banks know each other, have exchanged settlement instructions, and have agreed fees. A multilateral arrangement involves more than two banks, usually through a network, a clearing system, or a central hub. Instead of each bank holding accounts with every other bank, each bank holds one account with the hub, and the hub settles between all members. This reduces the number of accounts and the amount of liquidity each bank must hold. SWIFT gpi, regional clearing systems, and payment versus payment systems such as CLS are multilateral in spirit, because many banks connect through shared rules and infrastructure. Bilateral arrangements give control and a direct relationship, but they are expensive to maintain across many currencies. Multilateral arrangements are cheaper and more scalable, but they depend on the hub rules, its cut off times, and its membership criteria. Most large banks use both, bilateral accounts for their main currencies and multilateral systems for the rest.

De-risking is the practice where a bank ends or restricts a correspondent banking relationship because the risk of keeping it is seen as greater than the profit it earns. The bank is not necessarily saying the other bank has done anything wrong. It is saying the cost of monitoring the relationship, the risk of a sanctions breach, or the risk of a money laundering fine is too high for the revenue involved. Correspondent accounts are often closed for banks in higher risk countries, for banks with weak anti money laundering controls, for banks that process many high risk transactions, or for small banks whose payment volumes are too low to justify the compliance work. The effect is serious. When a correspondent closes an account, the affected bank loses its route to that currency, and its customers may face slower payments, higher charges, or no service at all in that corridor. Small island states, parts of Africa, and the Pacific have been hit hardest, because few correspondents want to serve them. Regulators have warned that blanket de-risking harms financial inclusion and can push payments into unregulated channels, which is riskier still. Banks are now expected to manage risk case by case, using better data and shared utilities, rather than closing whole regions at once. Even so, de-risking remains one of the biggest pressures on cross border payments today.

The serial and cover methods below are shown in their pre-migration MT form, because that form shows each method most clearly. Since coexistence ended on 22 November 2025, the same payment travels as a pacs.008 in serial, and as a pacs.008 plus a pacs.009 COV in cover. In correspondent banking, the payment and the cover are two different messages that together move money across borders, and the distinction matters most in the serial and cover methods. The payment message, usually an MT103, carries the full payment details to the beneficiary bank, including the debtor, the creditor, the amount, and the remittance information. The cover message, usually an MT202 COV, carries only the settlement instruction between banks, telling the correspondent how to move the funds to cover the payment. In the serial method, used mainly in the United States, a single MT103 travels from bank to bank in a chain, and each bank passes it on and settles with the next. In the cover method, used mainly in Europe, the MT103 goes directly to the beneficiary bank, while a separate MT202 COV moves the funds through the correspondent chain. The announcement, the MT103, usually arrives before the cover, so the beneficiary bank knows the payment is coming before the money arrives. Take the worked example. BNP Paribas Paris sends USD 367,574.90 to Banco Santander in Madrid. Under the cover method, Santander receives the MT103 directly, while the funds move from BNP Paribas through Wells Fargo, BIC PNBPUS3N, and then through Bank of New York Mellon, BIC IRVTUS3N, which holds the account for Santander, BIC BSCHESMM, before Santander credits its customer. The cover must carry enough information for sanctions screening, which is why the MT202 COV includes the underlying payment details.

Correspondent banks charge each other through a mix of account fees, per transaction fees, and deductions from the payment itself. The account agreement sets out a tariff, which typically includes a monthly account maintenance fee, a charge for each payment processed, a charge for each statement or report, and interest on overdrafts or credit balances. Some charges are billed monthly on an invoice, and the bank pays them by a separate transfer or by a direct debit from the nostro account. Other charges are taken directly from the payment as it passes through. In the worked example, Wells Fargo charged USD 20 and Bank of New York Mellon charged USD 22 on a USD 367,574.90 payment from BNP Paribas to Banco Santander. Those deductions were taken from the principal, so the final amount settled was USD 367,532.90, which is the original amount less USD 42 in correspondent charges. Whether a correspondent can deduct from the payment depends on the charge instruction, OUR, SHA, or BEN, and on the rules of the payment system used. Correspondents also earn money from FX spreads when they convert currency, and from value date differences, known as float, when they hold funds for a day before passing them on. Large banks negotiate volume discounts, and they review correspondent tariffs every year as part of the relationship review.

A nostro fee is any charge a correspondent bank levies for holding and operating a nostro account on behalf of another bank. The most common nostro fees are a monthly account maintenance fee, a per transaction fee for each payment or receipt processed through the account, a fee for statements and reporting, and a fee for investigations or repairs. The correspondent may also charge for liquidity services, such as an overdraft facility, and for FX conversion when it converts funds in the account. Nostro fees are set out in the account tariff agreed when the account is opened, and they are usually billed monthly. The account holder can pay the invoice by a separate payment, or authorise the correspondent to debit the nostro account directly. In practice, many nostro fees are small in isolation, for example USD 20 for processing a single payment, but they add up across thousands of payments a year, and they are one reason banks try to reduce the number of nostro accounts they hold. In the worked example, the USD 20 charged by Wells Fargo and the USD 22 charged by Bank of New York Mellon on the USD 367,574.90 payment are examples of nostro related transaction charges, deducted as the payment passed through each correspondent. Banks track these fees closely, because they feed directly into the total cost of a cross border payment and into the price charged to the end customer.

A correspondent bank has a legal duty to screen the payments it processes for sanctions, and it is one of the main control points in cross border payments. When a payment passes through a correspondent, the correspondent must check the names of the debtor, the creditor, and any intermediaries against sanctions lists issued by the United Nations, the European Union, the United States Office of Foreign Assets Control, and its own national regulator. It must also check the payment purpose, the countries involved, and any goods or services named in the remittance information. If a name matches a sanctioned person or entity, or if the payment involves a sanctioned country, the correspondent must stop the payment, hold the funds, and in many cases report the matter to its regulator. It must not simply pass the payment on and hope the next bank catches it. This is why the cover message, the MT202 COV, must carry the underlying payment details, so the correspondent can screen the real debtor and creditor, not just the banks in the chain. A correspondent that fails to screen properly faces large fines, loss of its banking licence, and loss of its own correspondent relationships. Because of this, correspondents invest heavily in screening software, and they may reject payments with incomplete or unclear information rather than risk a breach. A payment delayed for sanctions screening is therefore a normal control, not a service failure.

A bank monitors its nostro balances through a combination of intraday reporting, end of day statements, and liquidity dashboards, because a nostro balance is money held abroad that must be available when payments are released. During the day, the treasury or liquidity team watches live balances through the correspondent online portal, SWIFT MT942 interim statements, and internal payment queues. They track expected receipts and expected payments, and they compare the available balance with the payments scheduled for release. At the end of the day, the bank receives a full statement, usually an MT940 or MT950, and reconciles it against its own ledger. Any difference is investigated the next morning. Banks set internal limits for each nostro account, including a minimum balance to keep for the next day payments, a maximum balance to avoid holding too much idle cash, and an alert threshold that warns the team when the balance falls below a safe level. If the balance is too low, the team moves funds from another account, delays a non urgent payment, or arranges an overdraft. If the balance is too high, the team moves the excess to a higher yielding account or back to the home office. Good monitoring also covers value dates, so the team knows not just the balance today, but the balance that will be available tomorrow after pending settlements clear.

When a nostro account has insufficient funds, the correspondent cannot settle the payment in full, and the bank must act quickly to avoid a failed payment. The correspondent will usually do one of three things, depending on the account agreement. It may reject the payment and return it to the ordering bank with a reason code, it may hold the payment in a queue until funds arrive, or it may allow a short term overdraft up to an agreed limit and charge interest on the shortfall. The ordering bank treasury team is alerted at once, and it must either send funds to the nostro account, move funds from another currency account through an FX trade, or ask the correspondent for an intraday overdraft. If none of these is possible, the payment is delayed or returned, and the customer must be told. For example, if BNP Paribas tried to send USD 367,574.90 from a Wells Fargo nostro account holding only USD 300,000, Wells Fargo would not release the full amount unless an overdraft had been agreed. The payment could be queued, split, or rejected. Repeated shortfalls damage the relationship, because the correspondent bears the credit risk and the operational work of handling the failed instruction. Banks therefore forecast their nostro needs each morning, fund the accounts before the main payment cut off, and keep a buffer for unexpected large payments, rather than waiting for a shortfall to happen.

A settlement instruction, or SSI, tells a counterparty exactly where and how a payment should be settled, so the funds go to the right account at the right bank. It includes the currency, the account number, the name and BIC of the bank that holds the account, and any intermediary bank details needed to reach it. For example, the SSI for BNP Paribas US dollar payments might state that funds should be paid to its account with Wells Fargo, BIC PNBPUS3N, account number ending in a specific reference, while its euro payments settle through its own account at the European Central Bank. SSIs are exchanged when a relationship is set up, and they are stored in a central database used by the payment, treasury, and trading systems, so every department uses the same instruction. A wrong SSI is a common cause of failed or delayed payments, because funds sent to the wrong account must be recalled or returned. To reduce this risk, banks confirm SSIs with each other in writing, update them only through a controlled process, and validate them against the SWIFT SSI directory where available. In securities and FX trades, SSIs are even more important, because a trade can settle in a different place from the payment instruction, and a mismatch can leave a bank exposed. Every payment professional should treat an SSI as a controlled record, not a free text note.

A standing settlement instruction, or SSI, is a pre agreed settlement instruction that applies automatically to all future transactions with a counterparty, unless a specific trade says otherwise. Instead of agreeing the settlement account for every single payment, the two parties agree once that, for example, all US dollar payments from BNP Paribas to a particular counterparty will settle through its Wells Fargo account, BIC PNBPUS3N, and all euro payments will settle through its account in Paris. The instruction is then stored in both banks systems and applied by default. This saves time, reduces manual errors, and speeds up straight through processing, because the operations team does not need to ask for settlement details on every trade. Standing SSIs are common in FX, securities, and correspondent banking, where the same counterparties trade every day. They must still be maintained carefully. If a bank changes its correspondent, closes an account, or opens a new one, it must tell all its counterparties and update the standing instruction, or payments will keep going to the old account. Banks usually confirm standing SSIs once a year, and they require any change to be made in writing through an authorised channel, never by an email from an unknown sender, because a forged SSI change is a known fraud method. A standing instruction that is out of date is worse than no instruction at all.

Banks manage FX exposure on nostro accounts by keeping balances in each currency close to what they actually need, and by hedging any surplus or shortfall that remains. A nostro account in US dollars is an asset in dollars, so if the bank reports in euros, a fall in the dollar against the euro reduces the value of that balance in the bank accounts. To limit this, the treasury team sets a target balance for each currency, based on expected payments and receipts over the next few days. Balances above the target are sold, usually through an FX spot trade, and converted into the home currency or into a currency where funds are needed. Balances below the target are bought in advance. For larger or longer term exposures, the bank may use FX forwards or swaps to lock in a rate. For example, if BNP Paribas expects to hold USD 10 million in its Wells Fargo nostro account for a month, and it does not want the risk of the dollar falling, it can sell dollars forward and lock in the euro value today. Intraday, the team also watches for unexpected receipts, such as a large USD 367,574.90 payment that arrives without warning, and decides whether to keep the dollars for the next payment or convert them. Good FX management is therefore a mix of forecasting, limits, and hedging, not a single trade.

OUR, SHA, and BEN are charge instructions that decide who pays the fees on a cross border payment, and they are applied in the payment message so every bank in the chain knows what to do. With OUR, the sender pays all charges, including the sender bank fee, the correspondent fees, and the beneficiary bank fee. The beneficiary should receive the full amount. With SHA, the sender pays its own bank charges and the beneficiary pays the charges of the beneficiary bank and any intermediary charges deducted in transit. With BEN, the beneficiary pays all charges, so the amount credited is the original amount less every fee in the chain. In practice, SHA is the most common, and it was the instruction in the worked example, where a French company sent USD 367,574.90 to a Spanish company. Wells Fargo deducted USD 20 and Bank of New York Mellon deducted USD 22, so the beneficiary received USD 367,532.90. The sender bank cannot guarantee the exact final amount under SHA or BEN, because it does not control the intermediary fees. Under OUR, many banks now offer a guaranteed OUR service, where the sender pays a fixed fee up front and the beneficiary receives the full amount, with the sender bank absorbing any intermediary deductions. Customers should be told which option they have chosen, and what it means for the amount the beneficiary will receive.

Fields 71F and 71G are SWIFT MT103 fields that record charges on a cross border payment, and the difference between them is who bears the charge. Field 71F, Sender Charges, lists the charges deducted by the sending bank and by any intermediary bank, and it shows the amount and currency of each deduction. Field 71G, Receiver Charges, lists the charges that the beneficiary bank will deduct, or has deducted, from the amount before crediting the beneficiary. In a SHA payment, the intermediary deductions appear in field 71F, so the beneficiary bank can see what has already been taken. In the worked example, the USD 20 charged by Wells Fargo and the USD 22 charged by Bank of New York Mellon would be reported in field 71F, because they were taken in transit. The beneficiary bank, Banco Santander, would then report any charge it takes in field 71G. In an OUR payment, field 71F should show the charges that have been paid separately by the sender, and the beneficiary should receive the full amount. In a BEN payment, field 71G is more important, because the beneficiary bears all the charges. Operations teams use these fields to reconcile charges, to answer customer queries about why the received amount is lower than the sent amount, and to check that no bank has deducted a charge it was not entitled to take. In ISO 20022, the same information is carried in the charges elements of the pacs.008 message.

Intermediary banks deduct charges by taking a fee from the principal amount as the payment passes through them, unless the payment instruction says they must be paid separately. When an intermediary receives an MT103 for USD 367,574.90, it checks the charge instruction. If the instruction is SHA or BEN, it may deduct its fee, for example USD 20, before passing the remaining USD 367,554.90 to the next bank. It records the deduction in field 71F of the onward message, so the next bank and the beneficiary bank can see what was taken. If the instruction is OUR, the intermediary should not deduct from the principal. It should either claim its fee from the sender bank under a separate arrangement, or absorb the cost if a guaranteed OUR service applies. In practice, some intermediaries still deduct under OUR, which is why guaranteed OUR products exist and why customers sometimes complain that the beneficiary received less than promised. Intermediary charges are usually a flat fee per payment, often between USD 15 and USD 50, and they are set out in the correspondent tariff. They cover the cost of processing, screening, and settling the payment. A payment that passes through two intermediaries therefore loses two fees, as in the worked example, where Wells Fargo took USD 20 and Bank of New York Mellon took USD 22, leaving USD 367,532.90 for the beneficiary. This is why the number of intermediaries matters to the final cost.

Sender charges are the fees paid by the person or company that sends the payment, and receiver charges are the fees paid by the person or company that receives it. The sender bank normally charges the sender a fee for processing the payment, for example EUR 25 for a cross border transfer, and this is taken from the sender account at the time the payment is made. The receiver bank may charge the beneficiary a fee for receiving and crediting the payment, for example EUR 15, and this is taken from the amount credited or debited from the beneficiary account. Intermediary charges sit in between, and who pays them depends on the OUR, SHA, or BEN instruction. Under SHA, the sender pays the sender charges and the beneficiary pays the receiver charges plus any intermediary charges deducted in transit. Under OUR, the sender pays all charges, so the receiver should pay nothing. Under BEN, the beneficiary pays all charges. In the worked example, the French sender paid its own bank charges, while the Spanish beneficiary bore the USD 20 Wells Fargo charge and the USD 22 Bank of New York Mellon charge, because the instruction was SHA. The distinction matters for customer disclosure. A sender who expects the beneficiary to receive the full amount must choose OUR, and a beneficiary who expects to receive the full invoiced amount must check the charge instruction before accepting a SHA payment, because the amount credited will be lower than the invoice amount.

An FX rate is determined by supply and demand in the foreign exchange market, where banks, companies, and investors buy and sell currencies every second of the working day. The rate for a major pair such as EUR to USD is set by trading in the interbank market, where large banks quote prices to each other based on interest rates, economic data, central bank policy, and market sentiment. The published mid rate, often called the interbank rate, is the midpoint between the buying and selling prices in that market at a given moment. A bank that offers an FX rate to a customer starts from that mid rate and adds a margin, known as the spread, to cover its costs and its risk. The rate also depends on the size of the trade, the time of day, and whether the conversion is for immediate settlement or for a future date. A USD 367,574.90 payment converted from euros will get a better rate than a EUR 100 payment, because the bank can hedge a large trade more cheaply. The rate is fixed at the moment the bank accepts the customer instruction, not when the payment finally settles, unless the customer has agreed a forward rate in advance. Customers should always ask for the rate applied, the mid rate at the time, and the total cost in their own currency, so they can compare offers fairly.

A spot rate is the FX rate for a currency trade that settles immediately, normally two business days after the trade date, which is the standard settlement cycle in the FX market. If a company agrees to sell euros and buy US dollars at the spot rate today, the dollars will be delivered in two business days, and the rate is the current market rate at the moment of the deal. A forward rate is the rate agreed today for a trade that will settle on a future date, for example in one month or three months. The forward rate is not a forecast of where the market will be. It is calculated from the current spot rate plus the difference in interest rates between the two currencies for the period until settlement. If euro interest rates are lower than dollar interest rates, the forward rate for buying dollars will be higher than the spot rate, and vice versa. Companies use forwards to lock in a known cost for a future payment. For example, a French company that must pay USD 367,574.90 in three months can agree a forward rate today, so it knows exactly how many euros the payment will cost, whatever happens to the market in the meantime. The trade off is that if the market moves in its favour, it cannot benefit, because the rate is fixed. Banks offer forwards for standard periods, and they charge a margin over the theoretical forward rate.

The FX spread is the difference between the rate at which a bank buys a currency and the rate at which it sells the same currency, and it is one of the main ways banks earn money from FX. When a bank quotes EUR to USD, it will offer a slightly lower rate to a customer selling euros than the rate it offers to a customer buying euros. The gap between the two rates is the spread. The mid rate sits in the middle, and the spread is the bank margin around it. For a major currency pair such as EUR to USD, the interbank spread is very small, often less than 0.05 percent, because trading is heavy and competitive. For a customer, the spread is wider, often 0.5 percent to 2 percent, depending on the amount, the currency pair, and the channel used. A small payment through a branch may carry a spread of 2 percent, while a large corporate payment of USD 367,574.90 may carry a spread of 0.3 percent, because the bank can hedge it more cheaply. The spread is a hidden cost, because the customer sees only the rate offered, not the mid rate. A customer who converts EUR 100,000 at a spread of 1 percent pays EUR 1,000 in spread, even though no separate fee appears on the statement. This is why regulators now require banks to disclose the total cost of a currency conversion, including the spread, so customers can compare the true price.

Currency conversion in transit happens when a payment is sent in one currency but must be credited in another, and the conversion is done by a bank in the middle of the chain rather than by the sender or the beneficiary bank. For example, a French company may send euros to pay a supplier in Mexico, and the payment may be converted from euros to US dollars by the correspondent, then from dollars to Mexican pesos by the beneficiary bank. Each conversion uses the rate of the bank that performs it, and each bank adds its own spread. The customer often does not know how many conversions will happen, or what rates will be used, which is why the final amount can be much lower than expected. Banks handle this by stating the currency of the payment in the instruction, and by using the charge instruction to decide who pays for the conversion. Under SHA, the beneficiary bears the conversion cost. Under OUR, the sender should bear it, but in practice an intermediary may still convert and deduct a spread. To reduce surprises, many banks now offer a service where the sender bank converts the full amount at the start and sends the payment in the beneficiary currency, so no further conversion is needed. This is called a direct conversion, and it gives the sender a known rate and a known final amount. Customers should ask whether a conversion will happen in transit, and at what rate, before they send a payment in a currency different from the beneficiary account currency.

A nostro FX conversion is a currency conversion that a bank performs using the funds held in its own nostro account, rather than buying the currency in the market at the moment of the payment. For example, if BNP Paribas holds US dollars in its nostro account with Wells Fargo, and it needs to pay USD 367,574.90 to Banco Santander, it can use the dollars already in the account, with no FX trade needed. If instead it holds only euros in Paris and needs to pay dollars, it must sell euros and buy dollars, and that trade is settled by delivering dollars into the Wells Fargo nostro account. The conversion rate is the rate agreed for that trade, and the dollars are then available for the payment. Nostro FX conversions are managed by the treasury team, which watches the balance in each currency and decides when to buy or sell. If the dollar balance is too high, the team may sell dollars and buy euros to bring the balance back to target. If the balance is too low, the team buys dollars in advance. The conversion can be a spot trade for immediate needs, or a forward trade for a known future payment. The cost of the conversion is the FX spread plus any dealing charges, and it is separate from the payment charges deducted by the correspondents. Good nostro FX management means the bank always has the right currency in the right account at the right time, without holding large idle balances that earn little or no interest.

A direct FX rate is the rate for converting one currency straight into another, where the trade is made in the market for that pair. For example, EUR to USD is a direct rate, because euros and dollars are traded directly against each other in large volumes every day. A cross rate is the rate for converting between two currencies that are not traded directly in large volumes, so the conversion is done in two steps through a third currency, usually the US dollar. For example, there is little direct trading between the euro and the Mexican peso, so a bank converting euros to pesos will first convert euros to dollars, then dollars to pesos, and the combined rate is the cross rate. The cross rate is calculated by multiplying the two direct rates together. If EUR to USD is 1.08 and USD to MXN is 17.00, the EUR to MXN cross rate is 1.08 times 17.00, which is 18.36 pesos per euro. The customer pays a spread on each leg of the trade, so a cross rate conversion is usually more expensive than a direct conversion. This matters for payments to smaller currencies, where the beneficiary may receive less than expected because two spreads have been taken. Banks should tell the customer when a cross rate will be used, and what the final amount will be, so the customer can decide whether to send the payment in dollars instead and let the beneficiary bank do the final conversion.

Under PSD2, the revised Payment Services Directive in the European Union, banks must tell customers the full cost of a payment before the customer authorises it, and they must confirm the cost afterwards. Before the payment is made, the bank must show the amount, the currency, the FX rate that will be used if a conversion is involved, the total charges, and the estimated time the payment will take. If the payment is in euros within the European Economic Area, the charges must be shared under SHA, and the beneficiary must receive the full amount. For payments outside the area, the bank must show the charge instruction, OUR, SHA, or BEN, and explain what it means for the amount the beneficiary will receive. After the payment, the bank must give the customer a statement showing the amount debited, the charges taken, the FX rate actually applied, and the value date. The bank must also show the total cost of a currency conversion as a percentage mark up over the European Central Bank reference rate, so the customer can see the spread. These rules apply to retail and corporate customers, although some corporate disclosures can be agreed differently in the contract. The aim is to stop hidden charges, especially in FX, where a customer might see a small fee but pay a large spread. A bank that fails to disclose properly can face a complaint, a refund, and action from its national regulator.

The G20 target for cross border payment costs is part of the G20 Roadmap for Enhancing Cross Border Payments, agreed in 2020 and led by the Financial Stability Board, the Bank for International Settlements, and the Committee on Payments and Market Infrastructures. The headline target is that by 2027, the global average cost of a retail cross border payment should be no more than 1 percent of the amount sent, and no payment corridor should cost more than 3 percent. For remittances, the target is even tighter, reflecting the United Nations Sustainable Development Goal to cut the average cost of sending USD 200 to 3 percent or less. The roadmap also sets targets for speed, with 75 percent of payments credited within one hour by 2027, for access, with every end user having at least one payment option in every corridor, and for transparency, with every payment showing its full cost, its expected time, and its tracking status. Progress is measured each year against these targets, and the 2024 and 2025 reports showed costs falling slowly, but still well above 1 percent in many corridors, especially for small payments to Africa and parts of Asia. The targets matter because they give banks, fintechs, and regulators a shared goal, and they push investment in faster systems, better FX competition, and fewer intermediaries, all of which reduce cost.

The average cost of a cross border payment depends on who is sending it, how much they are sending, and which corridor they are using, but it is still high compared with a domestic payment. According to the World Bank, the global average cost of sending a USD 200 remittance was about 6.2 percent in 2024, which is USD 12.40 on a USD 200 payment. For larger corporate payments, the cost is lower as a percentage, often 0.5 percent to 2 percent, because the fixed fees are spread over a bigger amount and the FX spread is narrower. A USD 367,574.90 corporate payment might pay USD 42 in correspondent charges, as in the worked example, plus a sender bank fee of perhaps USD 30 and an FX spread of 0.3 percent if a conversion is involved, which would be about USD 1,100. That is still far more than a domestic transfer, which often costs nothing. The main cost drivers are the sender bank fee, the intermediary deductions, the beneficiary bank fee, and the FX spread, which is usually the largest part for small payments. Costs are highest in corridors with few correspondents, low volumes, or high compliance risk, and lowest in corridors such as EUR to USD, where competition is strong. Fintechs and new payment systems are bringing the average down, but the G20 target of 1 percent by 2027 shows how far the market still has to go.

Fintechs reduce cross border costs by cutting out intermediaries, by netting payments against each other, and by using better FX pricing. A traditional bank payment from Paris to Madrid in dollars may pass through Wells Fargo and Bank of New York Mellon, each taking a fee, as in the worked example. A fintech such as Wise or Revolut holds local accounts in many countries, so a payment from France to Spain can be settled locally at each end, with no cross border wire in between. The fintech nets the flows, so a euro payment going one way is matched against a euro payment going the other way, and only the net amount is moved across borders. This removes correspondent fees and reduces FX trades. Fintechs also show the mid market FX rate and charge a transparent percentage fee, often 0.4 percent to 0.8 percent, instead of hiding a wide spread in the rate. They use automated compliance screening and straight through processing, which cuts manual work and speeds up the payment to minutes or hours rather than days. They are not free of limits. They still need banking partners for settlement, they have lower limits for large corporate payments, and they must meet the same sanctions and anti money laundering rules as banks. Even so, their model has forced banks to cut fees, improve disclosure, and offer faster services, which benefits all customers.

A lifting fee is a charge made by a bank for lifting, or releasing, funds from a payment that has arrived, and it is most common in the Middle East and Asia, although the term is used in other regions too. When a payment arrives at the beneficiary bank, the bank may charge a lifting fee for processing the incoming transfer and crediting the beneficiary account. The fee is usually a flat amount, for example USD 10 to USD 25, or a small percentage of the amount, with a minimum and a maximum. It is separate from the sender bank fee and from any intermediary charges deducted in transit. In a SHA payment, the lifting fee is borne by the beneficiary, so it reduces the amount credited. In the worked example, if Banco Santander charged a lifting fee, it would be taken from the USD 367,532.90 that arrived after the Wells Fargo and Bank of New York Mellon deductions, and the beneficiary would receive even less. Lifting fees are often not shown in the original payment instruction, which is why customers are surprised when the credited amount is lower than expected. Under PSD2, banks in Europe must disclose any lifting fee before the payment is made, where it is known. Customers who receive regular payments should ask their bank what lifting fee applies to incoming transfers, and whether it can be waived for high value or regular customers, because the fee can add up to a large annual cost.

The full return flow in ISO 20022 is carried by the pacs.004 message, which is the Payment Return message used when a payment that has already been settled must be sent back to the sender. The flow starts when the beneficiary bank, or an intermediary, decides the payment cannot be credited, for example because the account is closed, the account number is wrong, or the beneficiary has rejected the payment. The returning bank creates a pacs.004 that references the original pacs.008, including its original instruction identification, its end to end identification, and its UETR, so the sender can match the return to the original payment. The pacs.004 carries the amount being returned, which may be the full amount or a partial amount, and a return reason code that explains why the payment is coming back. The message travels back along the same chain, through the same correspondents, and each bank debits the next bank and credits the previous bank, reversing the original settlement. Charges may be deducted by the returning banks, and those charges are shown in the message. The sender bank receives the pacs.004, credits its customer, and tells the customer why the payment was returned. In the worked example, if Banco Santander could not credit the Spanish company, it would send a pacs.004 back through Bank of New York Mellon and Wells Fargo to BNP Paribas, and the USD 367,532.90, less any return charges, would be returned to the French company. A return is not the same as a recall, because a return is started by the beneficiary side, not by the sender.

Return reason codes are standard codes that explain why a payment is being returned, so the sender can understand what went wrong without reading a free text note. In ISO 20022, the codes are four letter codes from the external return reason code list. Common codes include AC01, incorrect account number, AC04, closed account number, AC06, blocked account, AM05, duplicate payment, BE04, missing creditor address, CUST, requested by customer, DUPL, duplicate payment, FF01, invalid file format for the operation, FRAD, fraudulent payment, MS03, reason not specified, NARR, narrative reason, and RR04, regulatory reason. In the older MT system, the same reasons were given in field 72 as free text, which was harder to process automatically. A code of AC04 tells the sender at once that the beneficiary account is closed, and the sender must get a new account number before resending. A code of AM05 tells the sender that the payment was a duplicate, and it should not be resent. Banks must use the most accurate code available, and they must not use a generic code such as MS03 when a specific code applies, because a vague code forces the sender to investigate manually. Return reason codes also feed reporting, so banks can see which reasons are most common and fix the underlying problem, for example by improving account validation before a payment is released.

A return and a reversal both send money back, but they are started by different parties, for different reasons, and through different processes. A return is started by the beneficiary bank, or by an intermediary, when a payment cannot be credited as instructed. For example, if the beneficiary account is closed, the beneficiary bank returns the payment to the sender using a pacs.004, with a return reason code such as AC04. The sender did not ask for the money back. The beneficiary side decided it could not accept it. A reversal is started by the sender, or by the sender bank, to undo a payment that was made in error, for example a duplicate payment, a wrong amount, or a payment to the wrong beneficiary. A reversal is not a single message. It usually starts with a recall, a camt.056, asking the beneficiary bank to return the funds, and the beneficiary bank replies with a camt.029. If the beneficiary agrees, it returns the funds with a pacs.004. In short, a return is a rejection by the receiving side, while a reversal is a correction requested by the sending side. The timing also differs. A return usually happens quickly, within a day or two, because the beneficiary bank knows at once that it cannot credit the payment. A reversal can take days or weeks, because it depends on the beneficiary consent and on whether the funds are still available.

A recall is a request by the sender bank to the beneficiary bank to return a payment that has already been sent, and in ISO 20022 it is carried by the camt.056 message, the FI to FI Payment Cancellation Request. A recall is used when the sender has made a mistake, for example sending a duplicate payment, sending the wrong amount, sending to the wrong beneficiary, or sending a payment that was based on fraud. It is also used when the sender customer asks the bank to stop a payment after it has left the bank. The camt.056 must reference the original payment, including its UETR, its end to end identification, and its original instruction details, so the beneficiary bank can find the payment. It must also give a reason for the recall, such as duplicate payment or wrong beneficiary. The beneficiary bank is not obliged to return the funds automatically. It must check whether the funds are still in the beneficiary account, whether the beneficiary consents, and whether any legal reason prevents the return. In the worked example, if the French company realised it had sent USD 367,574.90 twice, BNP Paribas would send a camt.056 to Banco Santander, through the correspondent chain, asking for one payment to be returned. The recall does not move money by itself. It is a request, and the actual return happens only if the beneficiary bank agrees and sends a pacs.004.

The recall response is the reply a beneficiary bank sends when it receives a recall request, and in ISO 20022 it is carried by the camt.029 message, the Resolution of Investigation. When a bank receives a camt.056 recall, it must investigate the payment, check whether the funds are still available, contact the beneficiary if needed, and then reply with a camt.029. The response states whether the recall is accepted, partially accepted, or rejected, and it gives a reason. If the recall is accepted, the beneficiary bank will return the funds, usually with a pacs.004, and the camt.029 confirms that the return is in progress or has been made. If the recall is rejected, the camt.029 explains why, for example because the beneficiary has already withdrawn the funds, the beneficiary does not consent, or the account is closed with a zero balance. The camt.029 also carries the original recall reference, so the sender bank can match the reply to its request. The sender bank must tell its customer the outcome promptly, because the customer is waiting to know whether the money is coming back. A camt.029 is not a payment message. It does not move money. It is a status message that closes the investigation, or explains why the investigation cannot be closed yet. If no camt.029 arrives within the expected time, the sender bank should follow up with a status request, because a silent recall leaves the customer in doubt.

There is no single global time limit for a recall, because the limit depends on the payment system, the scheme rules, and the reason for the recall. In SWIFT gpi, a recall can be raised at any time after the payment has been sent, but the chance of success falls sharply once the beneficiary has withdrawn the funds. In the Single Euro Payments Area, under the SEPA Credit Transfer scheme, a recall can be raised within 10 business days of the execution date for a duplicate, a wrong amount, or a technical error, and within 13 months for a payment made without authorisation or as a result of fraud. In many domestic systems, the window is shorter, often 5 to 10 business days. After the scheme window closes, the sender bank can still ask the beneficiary bank for help, but the beneficiary bank is not obliged to follow the scheme process, and the sender may need to take legal action. The practical rule is simple. Raise a recall as soon as the error is found. Every hour matters, because the beneficiary may withdraw the funds, spend them, or move them to another account. In the worked example, if the French company spotted a duplicate USD 367,574.90 payment on the same day, BNP Paribas should send the camt.056 that day, before Banco Santander credits the second payment and the beneficiary withdraws it. A recall sent a month later is far less likely to succeed.

If the beneficiary has already withdrawn the funds, a recall will usually fail, because the beneficiary bank has no money left in the account to return. The beneficiary bank will check the account balance, and if the funds are gone, it will reply to the recall with a camt.029 stating that the recall is rejected because the funds are no longer available. It cannot take money from the beneficiary other account, and it cannot create money to cover the shortfall, unless a court orders it to do so. The sender bank must then tell its customer that the recall has failed, and the customer must try to recover the money directly from the beneficiary, for example by asking for a refund, by negotiating, or by taking legal action. If the payment was made as a result of fraud, the sender bank should report the fraud to the police and to its regulator, and it may be able to freeze other accounts held by the same beneficiary, but it cannot guarantee recovery. This is why speed matters so much. A recall sent within hours has a good chance of success, because the funds are often still in the account. A recall sent days later often fails. Banks therefore treat recall requests as urgent, and they have dedicated teams that act on them the same day. Customers should also be warned that a recall is a request, not a guarantee, and that the beneficiary consent is needed in many cases.

A payment investigation is the formal process a bank uses to find out what happened to a payment that is missing, delayed, or incorrect, and in the MT system it uses three messages. MT192 is a Request for Cancellation, sent when the sender wants a payment stopped before it settles. MT195 is a general Query, sent when the sender wants information, for example asking the beneficiary bank whether the payment was credited and on what date. MT196 is the answer to a query, sent by the bank that received the MT195, giving the status of the payment. Together, these messages form the investigation trail. In ISO 20022, the same work is done with camt.056 for a cancellation request, camt.028 for a status report, and camt.029 for the resolution of an investigation. An investigation is started when a customer reports a problem, for example saying the beneficiary has not received a USD 367,574.90 payment sent three days ago. The sender bank checks its own records, then sends an MT195 to the next bank in the chain, which forwards it until it reaches the beneficiary bank. Each bank replies, and the sender bank pieces together where the payment stopped. Investigations can take days, because each bank has its own cut off times and its own queue. Banks charge for investigations, often USD 25 to USD 50, and the charge may be passed to the customer if the investigation shows the bank did nothing wrong.

A claim for charges is the process where a bank asks another bank to pay a fee it believes it is owed for work done on a payment, and in the MT system it uses two messages. MT190 is an Advice of Charges, sent by a bank to tell another bank that a charge is due, for example a fee for an investigation, a repair, or a recall. MT191 is a Request for Payment of Charges, sent when the bank wants the other bank to pay that charge. The messages carry the amount, the currency, the reason for the charge, and the reference of the original payment, so the receiving bank can check the claim. In ISO 20022, the same information is carried in the charges elements of the relevant message, or in a camt.105, the Charges Payment Request. Claims for charges are common after exceptions. For example, if Banco Santander spends time investigating a missing USD 367,574.90 payment, and the investigation shows the delay was caused by BNP Paribas sending incomplete details, Santander may send an MT190 and MT191 to claim its investigation fee. The receiving bank can accept the claim and pay it, or reject it if it believes the charge is not justified, for example because the delay was its own fault. Banks have agreements that set the standard fees for investigations and repairs, so claims are usually for a fixed amount rather than a negotiated figure. Unpaid claims are followed up through the correspondent relationship, not through the payment chain.

A request for cancellation is a message from the sender bank asking the banks in the payment chain to stop a payment before it is credited to the beneficiary, and it is different from a recall, which asks for money back after it has been credited. In the MT system, a request for cancellation is an MT192. In ISO 20022, it is a camt.056 with a cancellation reason. A cancellation is used when the payment has been sent but has not yet reached the beneficiary, for example because it is still with a correspondent, or because the beneficiary bank has received the instruction but has not yet credited the account. The sender bank sends the cancellation to the next bank, which forwards it until it reaches the bank holding the payment. Each bank checks whether it can still stop the payment. If it can, it stops it and returns the funds. If it cannot, because the payment has already been credited, it tells the sender bank that a cancellation is no longer possible and a recall must be used instead. The chance of success depends on timing. A cancellation sent within minutes has a good chance, because the payment is still in transit. A cancellation sent the next day often fails. Banks treat cancellation requests as urgent, and they charge a fee for the work, whether the cancellation succeeds or not. Customers should be told that a cancellation is a best effort request, not a guarantee, and that the payment may already be beyond recall.

Reject, return, recall, and reversal are four different exception outcomes, and they are often confused, so it helps to place them on a timeline. A reject happens before settlement, when a bank refuses to process a payment because it fails a validation check, for example a wrong account number, a sanctions hit, or a missing mandatory field. The payment never leaves the rejecting bank. A return happens after settlement, when the beneficiary bank receives the payment but cannot credit it, for example because the account is closed. It sends the money back with a pacs.004 and a return reason code. A recall is a request by the sender to get money back after it has been credited, for example because the payment was a duplicate. It is sent as a camt.056, and the beneficiary bank replies with a camt.029. It depends on the beneficiary consent and on the funds still being available. A reversal is the overall outcome of undoing a payment, usually through a recall that is accepted and followed by a return. In other words, a reversal is the result, while a recall is the request that leads to it. A payment can be rejected, returned, or reversed, but the party who starts the action, the timing, and the message used are different in each case. Operations teams must use the right term in their reports, because a high reject rate points to a data problem, while a high recall rate points to a customer error problem.

A duplicate payment is a payment that is sent twice for the same underlying obligation, so the beneficiary receives the money two times instead of once. Duplicates happen for several reasons. A customer may click submit twice, a system may retry a payment after a timeout and send it again, or two different departments may each pay the same invoice. The first step when a duplicate is found is to stop any further payment for the same invoice and to check which payment is the valid one. The sender bank then raises a recall, a camt.056, for the duplicate payment, asking the beneficiary bank to return it. The beneficiary bank checks whether the funds are still in the account, and if they are, it returns them with a pacs.004. If the beneficiary has already withdrawn the funds, the recall will fail, and the sender must ask the beneficiary directly for a refund. Banks also try to prevent duplicates before they happen. They check for the same amount, the same beneficiary, and the same invoice reference sent within a short period, and they warn the operator before releasing the second payment. In ISO 20022, the UETR and the end to end identification help to spot duplicates, because a true duplicate will often carry the same end to end reference. In the worked example, if the French company sent USD 367,574.90 twice for invoice 103REF405775, the second payment would be a duplicate, and BNP Paribas should recall it at once, before the Spanish company withdraws the extra funds.

A payment repair is the manual work done to fix a payment that cannot be processed automatically because it has an error, missing data, or an unclear instruction. When a payment arrives at a bank and fails straight through processing, it is moved to a repair queue, where an operations analyst reviews it and decides what to do. Common repairs include fixing a wrong account number, adding a missing beneficiary address, correcting a wrong currency code, clarifying a vague remittance reference, or splitting a payment that exceeds a limit. The analyst may need to contact the sender bank for the correct details, using an MT195 query or a camt.028 status request. The repair must be done before the payment cut off, or the payment will be delayed to the next day. Repairs are expensive, because they take staff time and they slow the payment down, and they are often charged back to the sender bank or to the customer. Banks therefore measure their repair rate, which is the percentage of payments that need manual repair, and they work to reduce it by improving customer instructions, by validating account numbers before release, and by using structured data in ISO 20022, which leaves less room for free text errors. A payment that cannot be repaired, for example because the beneficiary cannot be identified at all, is returned to the sender with a pacs.004 and a reason code, rather than being held indefinitely.

An STP failure, or straight through processing failure, happens when a payment cannot flow automatically from the sender to the beneficiary without manual help, because something in the payment data is wrong, incomplete, or inconsistent with the bank systems. Straight through processing means the payment is validated, screened, settled, and credited with no human touch, and it is the goal for most payments because it is fast and cheap. An STP failure breaks that chain. Common causes include a missing or invalid IBAN, a beneficiary name that does not match the account, a missing purpose code, a sanctions screening hit that needs review, or a value date that falls on a holiday. When an STP failure happens, the payment is routed to an exception queue, and an analyst investigates it. The fix depends on the cause. A wrong IBAN is corrected from the customer instruction or by asking the sender bank. A sanctions hit is reviewed by the compliance team, which decides whether it is a true match or a false positive. A missing field is added from the original instruction. Once fixed, the payment is released back into the automated flow. If it cannot be fixed, it is returned or rejected. Banks track their STP rate, which is the percentage of payments that process without manual help, and a rate below 95 percent is usually seen as a problem, because manual work costs money and delays payments.

A payment amendment is a change to a payment instruction after it has been sent but before it has been finally settled, for example correcting a beneficiary name, changing an account number, updating a remittance reference, or changing the value date. Amendments are needed when the sender spots an error, or when the beneficiary asks for a correction, and they are processed through a formal request, not by editing the original message. In the MT system, an amendment is usually sent as an MT195 query with the corrected details, or as a new instruction that cancels and replaces the old one. In ISO 20022, an amendment can be sent as a camt.056 cancellation request followed by a new pacs.008, or as a pacs.008 amendment where the scheme allows it. The bank that receives the amendment must check whether the payment can still be changed. If the payment is still with the sender bank, the change is easy. If it is already with a correspondent, the correspondent must be asked to apply the change, and it may charge a fee. If the payment has already been credited to the beneficiary, an amendment is no longer possible, and the sender must use a recall instead. Amendments are treated as urgent, because a payment with the wrong beneficiary details may be returned or credited to the wrong person. Customers should therefore check payment details carefully before release, because an amendment after release is slower, more expensive, and less certain than getting it right first time.

SWIFT gpi, or Global Payments Innovation, is a service launched by SWIFT in 2017 to make cross border payments faster, more transparent, and easier to track. Before gpi, a sender had no way to know where a payment was, how much had been deducted, or when it would arrive. Gpi changes that by giving every payment a unique end to end transaction reference, the UETR, and by requiring every gpi bank in the chain to confirm receipt, to confirm credit, and to report any charges deducted. The payment is tracked from the sender bank to the beneficiary bank, and the sender can see each step, including the time each bank received the payment and the amount it passed on. Gpi also sets service level agreements, so banks must confirm credit within a set time, and it provides a case resolution service for problems. By 2024, most large banks had joined gpi, and more than half of all SWIFT cross border payments were gpi payments. Gpi does not move money itself. It runs on top of the existing correspondent banking network, using the same nostro accounts and the same settlement systems. What it adds is a tracking layer, a set of rules, and a shared data standard. A gpi payment therefore still passes through correspondents such as Wells Fargo and Bank of New York Mellon, but the sender can now see that it did, and how much each bank charged.

The UETR, or Unique End to End Transaction Reference, is a 36 character identifier that follows a cross border payment from the sender to the beneficiary, and it is the key to SWIFT gpi tracking. The format is the standard Universally Unique Identifier format, written as eight hexadecimal characters, a hyphen, four characters, a hyphen, four characters, a hyphen, four characters, a hyphen, and twelve characters, for example 123e4567-e89b-12d3-a456-426614174000. The UETR is generated by the sender bank when the payment is created, and it must stay the same for the whole life of the payment, including any returns, recalls, or investigations that follow it. Every bank in the chain must carry the UETR forward in its onward message, so the payment can be tracked end to end. In an MT103, the UETR is carried in field 121. In a pacs.008, it is carried in the UETR element. The UETR is not the same as the payment reference, such as 103REF405775 in the worked example, which is a business reference chosen by the sender. The UETR is a technical tracking reference, and it is unique across the whole SWIFT network. If a bank fails to carry the UETR forward, the payment drops out of gpi tracking, and the sender loses visibility. Banks therefore validate the UETR on receipt, and they reject or repair payments that arrive without one where gpi is expected.

Gpi tracking works by giving every payment a UETR and by requiring every gpi bank in the chain to send a confirmation to the SWIFT gpi Tracker when it receives the payment, when it passes it on, and when it credits the beneficiary. When BNP Paribas sends a USD 367,574.90 payment to Banco Santander, it generates a UETR and sends the payment to Wells Fargo. Wells Fargo confirms receipt to the Tracker, deducts its USD 20 charge, and passes the payment to Bank of New York Mellon, which also confirms receipt. Bank of New York Mellon deducts USD 22 and passes the payment to Santander, which confirms receipt and then confirms credit to the beneficiary account, with the final amount of USD 367,532.90 and the time of credit. Each confirmation is sent as a gpi confirmation message, and the Tracker assembles them into a single view that shows the payment status, the time at each step, the charges deducted, and the FX rate if a conversion happened. The sender bank can show this view to its customer, either in online banking or on request. If a bank does not confirm within the agreed time, the Tracker flags the payment as overdue, and the sender bank can chase it. Tracking works only if every bank in the chain is a gpi member and carries the UETR forward. If a non gpi bank is involved, tracking stops at that point, and the payment becomes invisible until it reaches the next gpi bank.

The gpi Tracker is the central database and user interface provided by SWIFT that collects confirmations from gpi banks and shows the status of a gpi payment end to end. Each gpi bank sends a confirmation to the Tracker when it receives a payment, when it forwards it, and when it credits the beneficiary. The Tracker stores these confirmations against the UETR, and it builds a timeline that shows the payment journey, the amount at each step, the charges deducted, and the time taken. A bank can access the Tracker through a web portal, through an API that feeds its own systems, or through its SWIFT Alliance interface. The sender bank can look up a payment by UETR and see where it is, and it can share that view with its customer. The Tracker also provides a payment status, such as in progress, credited, or rejected, and it flags payments that are overdue against the gpi service level agreement. The Tracker does not move money. It only records what banks report, so its accuracy depends on banks sending confirmations promptly and correctly. If a bank is late in confirming, the Tracker will show the payment as still with the previous bank, even though it has actually moved on. SWIFT monitors confirmation rates and publishes league tables, which puts pressure on banks to confirm on time. For customers, the Tracker is the main benefit of gpi, because it replaces the old answer of we do not know where your payment is with a clear, timed record.

The gpi Observer is a SWIFT tool that monitors how well banks are following the gpi rules, and it gives each bank a score based on its performance. It tracks whether banks confirm payments on time, whether they carry the UETR forward correctly, whether they report charges accurately, and whether they follow the gpi service level agreements. The Observer collects data from the gpi Tracker, and it produces dashboards and reports that show each bank how it compares with its peers, without naming other banks individually. A bank with a low score can see where it is failing, for example if it confirms only 80 percent of payments within two hours while the target is 95 percent, and it can fix its processes. SWIFT also uses Observer data to identify banks that are not meeting the gpi rulebook, and it can raise the issue with them directly. The Observer is not a customer facing tool. Customers do not see Observer scores, but they benefit indirectly, because banks that want a good score invest in faster confirmations and better data. The Observer also helps SWIFT to prove that gpi is working, by publishing aggregate figures on speed, transparency, and confirmation rates. For a payments professional, the Observer is a useful reminder that gpi is not just a tracking screen, but a set of rules with monitoring behind it, and that a bank reputation in the network depends on meeting those rules consistently.

Gpi SLAs, or service level agreements, are the time limits that gpi banks agree to meet when they process a gpi payment, and they are set out in the SWIFT gpi Rulebook. The main SLA is that a bank must confirm receipt of a payment and confirm credit to the beneficiary within a set time, usually within two hours of receiving the payment during its business hours, and in any case by the end of the business day. If a bank cannot credit the payment within that time, it must send a status update to the Tracker explaining why, for example because it is waiting for more information from the beneficiary. There are also SLAs for investigations, where a bank must respond to a gpi case within a set time, and for the accuracy of charge reporting, where a bank must report the amount it deducted correctly. Banks that miss SLAs are flagged in the gpi Observer, and repeated failures can affect their standing in the gpi community. SLAs matter because they turn tracking into accountability. Before gpi, a bank could hold a payment for days with no explanation. Under gpi, it must either confirm credit or explain the delay, and the sender can see the delay in the Tracker. For a USD 367,574.90 payment from Paris to Madrid, the gpi SLA means Santander should confirm credit on the same day, and Wells Fargo and Bank of New York Mellon should each confirm their step within hours. Customers should ask their bank what gpi SLAs apply to their payments, and what happens if the bank misses them.

Gpi Case Resolution is the SWIFT gpi service that helps banks solve problems with a gpi payment quickly, by giving them a shared case file linked to the payment UETR. When a payment is delayed, missing, or incorrect, the sender bank can open a case in the gpi Tracker, and it can send a message to the bank that currently holds the payment, asking for an update. The receiving bank must respond within the gpi SLA, and all messages in the case are stored in one place, so no one has to search through emails or phone notes. The case can cover many issues, including a payment that has not been credited, a wrong amount, a missing beneficiary, or a request for a refund. Case Resolution replaces the old MT195 and MT196 investigation messages for gpi payments, although banks can still use those messages for non gpi payments. The advantage is speed and clarity. Because the case is linked to the UETR, every bank in the chain can see the same information, and the sender bank can tell its customer what is happening without waiting for a reply to an email. Cases are closed when the problem is solved, for example when the payment is credited or returned, and the closure is recorded in the Tracker. Banks are expected to use Case Resolution for gpi payments, and SWIFT monitors how quickly they respond, as part of the gpi Observer. For customers, Case Resolution means a problem is less likely to sit unanswered for days.

SWIFT gpi and SWIFT Go are both SWIFT services, but they serve different payment types. Gpi is for high value cross border payments, usually corporate or large retail payments, where tracking, transparency, and speed matter, and where the amount can be large, for example USD 367,574.90. Gpi gives the sender a UETR, a Tracker view, confirmations from every bank, and service level agreements. SWIFT Go is for low value cross border payments, usually under USD 10,000, sent by small businesses and consumers, for example an online purchase or a payment to a freelancer. SWIFT Go is designed to be fast, cheap, and simple, with a predictable fee and a predictable delivery time, often within minutes or hours. It uses a single upfront fee, and the beneficiary receives the full amount, with no deductions in transit. It does not offer the same detailed tracking as gpi, although the sender still gets a confirmation when the payment is credited. The two services can run side by side in the same bank. A corporate payment of USD 367,574.90 would use gpi, while a consumer payment of USD 200 to a friend abroad would use SWIFT Go. The choice depends on the amount, the customer type, and the need for tracking. Banks should explain which service they are using, and what the customer can expect, because the fee, the speed, and the information provided are different.

The gpi pre-validation service, also called SWIFT gpi pre-validation or Payment Pre-validation, is a service that lets a sender bank check whether a beneficiary account exists and whether the payment details are correct, before the payment is sent. The sender bank sends the beneficiary account number, the beneficiary name, and the beneficiary bank BIC to the pre-validation service, which asks the beneficiary bank to confirm the details. The beneficiary bank replies within seconds, saying whether the account is valid, whether the name matches, and whether the account can receive the payment in the requested currency. This check happens before any money moves, so it prevents the most common reasons for returns, such as a wrong account number or a closed account. Pre-validation does not guarantee that the payment will be credited, because the account could be blocked after the check, or the beneficiary could have insufficient funds for a direct debit, but it catches most data errors early. The service is especially useful for new beneficiaries, for high value payments such as USD 367,574.90, and for payments to countries where account formats are complex. Banks that use pre-validation report lower return rates and fewer repairs, which saves time and money. Customers benefit because their payment is less likely to be returned, and they get a faster, more reliable service. Pre-validation is a paid service, and the cost is usually borne by the sender bank.

When a gpi payment leaves the gpi network, tracking stops at the last gpi bank, and the sender loses visibility until the payment reaches another gpi bank or the beneficiary bank. This happens when a payment passes through a bank that is not a gpi member, or when it moves from SWIFT into a domestic system that does not support gpi, such as a local clearing system in the beneficiary country. The last gpi bank sends its confirmation to the Tracker, and then the payment goes dark. The sender bank can see that the payment left the gpi network, but it cannot see where it is, how long it will take, or what charges will be deducted. This is a known limit of gpi, and SWIFT is working to extend coverage by bringing more banks into gpi and by linking gpi to domestic instant payment systems. In practice, the payment still moves through the normal correspondent chain, and the beneficiary bank will still credit it, but the customer must wait for a confirmation from the beneficiary, rather than seeing it in the Tracker. For example, a USD 367,574.90 payment from BNP Paribas to Banco Santander stays in gpi all the way, because both banks and their correspondents are gpi members. A payment to a small bank in a country with low gpi coverage might leave the network after Wells Fargo, and the sender would not know when it was credited. Banks should warn customers when a payment will leave gpi, so they do not expect full tracking.

A clearing house is an organisation that sits between buyers and sellers, or between banks, and manages the exchange, matching, and netting of payment instructions before they are settled. In payments, a clearing house receives payment instructions from many banks, sorts them by beneficiary bank, checks them for errors, and calculates what each bank owes every other bank. It does not usually move the money itself. That is done at settlement, when the net amounts are transferred between settlement accounts. In securities and derivatives, a clearing house does more. It becomes the buyer to every seller and the seller to every buyer, a role called central counterparty clearing, and it guarantees the trade even if one side fails. Clearing houses are important because they reduce risk and cost. Without a clearing house, every bank would need a direct relationship with every other bank, and would need to settle thousands of individual payments. With a clearing house, each bank deals only with the clearing house, and settles one net amount. Examples include the Clearing House Interbank Payments System in the United States, the Euro Banking Association clearing system in Europe, and the National Clearing House in many other countries. Clearing houses are regulated as systemically important, because a failure would disrupt the whole payment system.

A CSM, or Clearing and Settlement Mechanism, is the full system that clears and settles payments, while a clearing house is one type of organisation that can provide clearing services within that system, so the terms overlap but are not identical. In the Single Euro Payments Area, a CSM is defined as the entity that carries out clearing and settlement for SEPA payments. It receives payment instructions, exchanges them between banks, calculates net positions, and settles them, usually in central bank money through TARGET. A clearing house, in the narrower sense, is an organisation that performs the clearing part only, which is the exchange, matching, and netting of instructions, and it may pass the net settlement to a separate settlement system. Some clearing houses also do settlement, and some CSMs are operated by a clearing house, which is why the terms are often used interchangeably. The key difference is scope. A CSM is a defined role in a payment scheme, with scheme rules, membership criteria, and a settlement arrangement. A clearing house is a type of institution, which may operate a CSM, or may provide clearing for securities, derivatives, or other markets. For example, EBA CLEARING operates STEP2, which is a CSM for SEPA payments, and it also operates other services. A bank joining SEPA must connect to a CSM, and it must understand whether that CSM also settles, or whether settlement happens elsewhere, because that affects timing and liquidity.

Bilateral clearing is clearing between two parties directly, with no central clearing house in between. Two banks agree to exchange payment instructions with each other, match them, and calculate what one owes the other, and then settle that net amount between themselves. For example, BNP Paribas and Banco Santander could agree to clear their euro payments bilaterally. During the day, BNP Paribas sends Santander all its payments for Santander customers, and Santander sends BNP Paribas all its payments for BNP Paribas customers. At the end of the day, they net the two totals. If BNP Paribas sent EUR 10 million and Santander sent EUR 8 million, BNP Paribas owes Santander a net EUR 2 million, and only that amount is settled. Bilateral clearing is simple and it works well when two banks have a large, regular flow between them, because it avoids the cost of joining a central system. It has limits. It requires a direct agreement, a shared cut off time, and a settlement account between the two banks. It also leaves each bank exposed to the other, because if one bank fails before settlement, the other may lose money. For this reason, bilateral clearing is common for a small number of high volume pairs, while most payments go through multilateral clearing, where a central system nets all banks together and reduces the number of settlements and the exposure to any single bank.

Multilateral clearing is clearing where many banks send their payment instructions to a central system, which nets all the instructions together and calculates one net position for each bank against the system as a whole, rather than against each other bank. For example, if BNP Paribas, Banco Santander, Wells Fargo, and Bank of New York Mellon all send payments to each other during the day, a multilateral clearing system collects every instruction, adds up what each bank is owed and what each bank owes, and produces a single net debit or credit for each bank. A bank that sent USD 367,574.90 to one bank, received USD 200,000 from another, and sent USD 100,000 to a third, would settle only its net position, not three separate payments. This is far more efficient than bilateral clearing, because the number of settlements falls from many pairs to one per bank. It also reduces liquidity needs, because banks need only the net amount, not the gross amount, to settle. Multilateral clearing is used by most domestic payment systems, by SEPA clearing systems such as STEP2, and by card schemes, where millions of transactions are netted each day. The system operator must be trusted, well capitalised, and well regulated, because all members rely on it. If the clearing system fails, every member is affected, which is why multilateral systems are classed as systemically important.

A clearing cycle is a defined period during which payment instructions are collected, exchanged, and netted, before the resulting net amounts are settled. Most clearing systems run several cycles a day, each with a cut off time. Payments received before the cut off are included in that cycle, and payments received after the cut off wait for the next cycle. For example, a system might run cycles at 09:00, 12:00, 15:00, and 17:00. A payment sent at 11:30 would be included in the 12:00 cycle, netted with other payments in that cycle, and settled shortly after. A payment sent at 12:05 would wait for the 15:00 cycle. The length and number of cycles affect speed. A system with many cycles a day settles payments faster than a system with one cycle a day. Instant payment systems have effectively continuous cycles, with settlement in seconds. Clearing cycles also affect liquidity, because banks must have funds available at settlement time for each cycle, not just at the end of the day. Operations teams plan their payment releases around cycle cut offs, and they warn customers that a payment sent after the last cycle will not settle until the next business day. In cross border payments, the clearing cycle of the domestic system must be aligned with the correspondent cut off, or the payment may miss the cycle and be delayed by a day.

A clearing account is an internal account a bank uses to hold payments that are in the process of clearing, before they are settled or credited to the customer. When a bank receives a payment instruction, it may first credit the clearing account, then, once the payment has been checked, matched, and netted, it moves the funds to the beneficiary account or to the settlement account. Clearing accounts are also used between banks. A bank may hold a clearing account with a clearing house, where its net position for the day is recorded, and settlement is made by debiting or crediting that account. Clearing accounts are not customer accounts. Customers do not see them, and they do not earn interest for the customer. They are a control tool, which lets the bank track payments that are in transit, reconcile them, and prove that every payment that entered clearing has either been settled or returned. If a payment is stuck in a clearing account for too long, it is a sign of a problem, such as a missing beneficiary detail or a failed match. Operations teams monitor clearing account balances daily, and they investigate any old items, because a payment left in clearing is a payment that has not reached its beneficiary, and it may need to be returned or repaired. Good clearing account discipline is a sign of a well run payments operation.

A central counterparty, or CCP, is an organisation that sits between the buyer and the seller in a trade, and becomes the buyer to every seller and the seller to every buyer, so that each party deals only with the CCP, not with each other. In payments, the CCP role is less common than in securities and derivatives, but the principle is the same. When two banks clear a payment through a CCP, the CCP guarantees settlement, even if one bank fails before settlement. It does this by requiring members to post margin, which is collateral that can be used if a member defaults, and by maintaining a default fund contributed by all members. The CCP also nets trades, so each member settles one net amount with the CCP, rather than many amounts with many counterparties. This reduces risk and liquidity needs. The CCP must be well capitalised, well managed, and closely supervised, because if it fails, the whole market it serves is at risk. Examples include LCH for derivatives and Eurex Clearing for securities. In payments, some clearing houses perform a similar function, although they do not always guarantee settlement in the same way. A payments professional should understand that a CCP does not remove risk. It concentrates risk in one place, and it manages that risk through margin, default funds, and strict membership rules, which is why CCPs are classed as systemically important.

Clearing reduces the number of settlements by netting many individual payment instructions down to a small number of net amounts, so banks settle only the difference, not every payment. Without clearing, if four banks each send ten payments to each other, they would need to settle 40 separate payments, each with its own liquidity and its own operational work. With clearing, the clearing system collects all 40 instructions, adds up what each bank owes and what each bank is owed, and calculates one net position per bank. A bank that sent USD 367,574.90 in total and received USD 300,000 in total would settle only the net USD 67,574.90, in one settlement, instead of settling every payment individually. This is called multilateral netting, and it is the main benefit of clearing. It reduces the number of settlements, the amount of liquidity needed, and the operational cost, because the bank moves money once, not 40 times. It also reduces settlement risk, because fewer settlements mean fewer chances for a payment to fail. The trade off is that netting creates a delay, because payments must wait for the clearing cycle to finish before they settle, and it creates exposure to the clearing system, because all members rely on it to calculate the net correctly. Even so, for high volume, low value payments, netting is far more efficient than settling each payment gross, which is why it is used by almost every domestic payment system.

DNS, or Deferred Net Settlement, and RTGS, or Real Time Gross Settlement, are the two main settlement models, and they differ in timing, liquidity, and risk. In DNS, payments are collected during the day, netted at set times, and settled as one net amount per bank, usually at the end of a clearing cycle. A bank that sent USD 367,574.90 and received USD 300,000 would settle only the net USD 67,574.90. DNS is cheap and needs little liquidity, because only the net amount moves, but it is slower, and it carries settlement risk, because a bank could fail between the time a payment is sent and the time it settles. In RTGS, each payment is settled individually, in real time, in central bank money, as soon as it is received, provided the sending bank has enough funds in its central bank account. A USD 367,574.90 payment would settle in full, at once, with finality. RTGS is fast and safe, but it needs a lot of liquidity, because the bank must have the full amount available for every payment. In practice, most countries use both. RTGS is used for high value, urgent payments, such as TARGET in Europe, Fedwire in the United States, and CHAPS in the United Kingdom. DNS is used for high volume, low value payments, such as retail transfers, direct debits, and card payments, where netting saves liquidity and cost. A bank must choose the right model for each payment, based on its value, its urgency, and its liquidity.

A hybrid settlement model combines the features of RTGS and DNS, to get the speed and safety of RTGS with the liquidity saving of DNS. In a pure RTGS system, every payment settles gross, in real time, which needs a lot of liquidity. In a pure DNS system, payments wait for a net settlement, which saves liquidity but is slower and riskier. A hybrid system lets banks choose, or it automatically offsets payments against each other during the day, so that many payments settle gross, but the system first checks whether an incoming payment can be used to fund an outgoing payment, reducing the amount of new liquidity needed. For example, if BNP Paribas has a USD 367,574.90 payment waiting to go to Banco Santander, and a USD 300,000 payment from another bank is about to arrive, a hybrid system can offset the two, so BNP Paribas needs only USD 67,574.90 in new funds to settle the outgoing payment. Hybrid systems also use queues, priority levels, and liquidity saving mechanisms to manage payments that cannot settle at once. TARGET2 in Europe and many modern RTGS systems are hybrid in practice, because they include liquidity saving features on top of gross settlement. The benefit is clear. Banks settle faster than in DNS, with less risk, and they need less liquidity than in pure RTGS. The cost is complexity, because the system must manage queues, offsets, and priorities in real time.

A liquidity saving mechanism, or LSM, is a feature in a modern RTGS system that reduces the amount of liquidity banks need to settle their payments, by offsetting payments against each other before they settle. Without an LSM, a bank must have the full amount of every outgoing payment in its central bank account before the payment can settle. With an LSM, the system looks at the queue of payments waiting to settle, and it finds pairs or groups of payments that can be offset. For example, if Bank A owes Bank B USD 367,574.90, and Bank B owes Bank A USD 300,000, the LSM can settle both payments together using only USD 67,574.90 in new liquidity, because the USD 300,000 cancels out. The LSM runs at set intervals, or continuously, and it can handle complex groups involving many banks. It can also use bilateral and multilateral offsetting, and it can respect payment priorities, so urgent payments settle first. LSMs are now standard in TARGET, Fedwire, and other major RTGS systems, because they cut liquidity needs by 20 percent to 50 percent in many cases, without slowing settlement much. Banks benefit because they can hold less idle cash at the central bank, and they are less likely to face a queue or a gridlock. The LSM does not change finality. Once a payment is settled through an LSM, it is final, just as in normal RTGS.

Queue management in RTGS is the process of handling payments that cannot settle at once because the sending bank does not have enough funds in its central bank account. When a bank submits a payment to an RTGS system such as TARGET or Fedwire, the system checks the bank balance. If the balance is enough, the payment settles at once. If it is not enough, the payment is placed in a queue, and it waits until funds arrive, either from an incoming payment, from a transfer from another account, or from a central bank loan. The bank can manage its queue in several ways. It can set priorities, so urgent payments settle before normal payments. It can cancel a payment in the queue, or change its priority. It can also use a liquidity saving mechanism to offset a queued payment against an incoming payment. The RTGS operator monitors queues across all banks, and it may intervene if a queue is growing too long, for example by running a gridlock resolution. Good queue management matters because a payment stuck in a queue delays the beneficiary, and it can cause a chain reaction, where one bank waiting for funds delays another bank, and so on. Banks therefore monitor their queues intraday, forecast their liquidity needs, and release payments in an order that matches their expected receipts, rather than releasing all payments at once in the morning and hoping funds will arrive.

Gridlock resolution is the process an RTGS system uses to break a deadlock where several banks are each waiting for funds from another bank, so none of their queued payments can settle, even though the system as a whole has enough liquidity. For example, Bank A owes Bank B USD 367,574.90, Bank B owes Bank C USD 300,000, and Bank C owes Bank A USD 250,000. No bank has enough funds to pay on its own, so all three payments sit in queues, and no one can move. A gridlock resolution algorithm looks at all the queued payments together, finds a group that can be settled if they are settled simultaneously, and settles them together, using only the net liquidity needed. In this example, the three payments can be settled together with a much smaller amount of new funds, because each bank receives money at the same time as it pays money. RTGS operators run gridlock resolution at set intervals, or when a queue reaches a threshold, and they use it as a safety valve to keep the system flowing. Banks can also help by not holding payments back, by using liquidity saving mechanisms, and by borrowing from the central bank intraday. Gridlock is rare in normal times, because banks usually have enough liquidity, but it can happen on a busy day, or when a large bank has a technical problem. Without gridlock resolution, a deadlock could last for hours and delay thousands of payments.

A settlement window is a defined period during which a payment system settles payments, and it is set by the system operator, usually the central bank. Outside the window, payments can be submitted and queued, but they will not settle until the next window opens. For example, TARGET in Europe is open from 07:00 to 18:00 Central European Time on business days, and payments submitted after 18:00 wait until the next morning. Fedwire in the United States is open for most of the day, but it has a cut off for customer payments earlier than for bank to bank payments. Settlement windows matter for three reasons. First, they set the deadline for a payment to be settled on a given value date. A payment sent after the window closes will have a value date of the next business day. Second, they affect liquidity, because banks must have funds available during the window, and they can use the time outside the window to fund their accounts. Third, they affect cross border payments, because the window in the sending country must overlap with the window in the receiving country, or the payment will wait. A USD 367,574.90 payment from Paris to Madrid must be sent in time to meet the TARGET window and the correspondent cut off at Wells Fargo, or it will settle a day later. Banks publish their settlement windows to customers, and they warn customers about cut off times, so a payment is not sent too late.

Finality of settlement means that once a payment has been settled, it cannot be revoked, reversed, or unwound, even if the sending bank fails afterwards. The payment is final, the beneficiary bank owns the funds, and the beneficiary can use them at once. Finality is a legal concept, not just a technical one, and it is set out in law, such as the EU Settlement Finality Directive, and in the rules of the payment system. In RTGS, finality happens at the moment the central bank debits the sender account and credits the receiver account. In DNS, finality usually happens at the moment the net settlement is made, although some systems give finality earlier, when the payment is accepted into clearing. Finality matters because it removes settlement risk. A bank that receives a final payment does not need to worry that the money will be taken back if the sender fails. Without finality, banks would be reluctant to release funds to customers, because they could lose the money. Finality also matters in a crisis. If a bank fails during the day, payments it made before its failure that have reached finality stay settled, and payments that have not reached finality may be unwound. This is why central banks and regulators insist on clear finality rules, and why banks check the finality point for each system they use, before they credit a customer for a large payment such as USD 367,574.90.

Settlement in central bank money means the payment is settled by moving funds between accounts held at the central bank, for example the European Central Bank or the Federal Reserve. Settlement in commercial bank money means the payment is settled by moving funds between accounts held at a commercial bank, for example a nostro account with Wells Fargo. Central bank money is the safest form of settlement, because a central bank cannot fail in its own currency, and a payment settled in central bank money is final and risk free. This is why RTGS systems such as TARGET and Fedwire settle in central bank money, and why they are used for high value payments. Commercial bank money carries credit risk, because the commercial bank holding the account could fail before the payment settles. A USD 367,574.90 payment settled through a Wells Fargo nostro account is settled in commercial bank money, and BNP Paribas is exposed to Wells Fargo until the payment is passed on. In practice, most cross border payments settle in commercial bank money through correspondents, because the sender and receiver do not both hold accounts at the same central bank. Most domestic high value payments settle in central bank money. Banks manage the difference by limiting their exposure to any one commercial bank, by using central bank money where possible, and by understanding that a payment is not truly risk free until it has been settled in central bank money or credited to the beneficiary.

Banks forecast intraday liquidity needs by predicting, hour by hour, how much money will come in and go out of their settlement accounts during the day, so they can have enough funds available without holding too much idle cash. The forecast starts the previous evening, with the expected opening balance, the payments already queued, and the known value dates for the next day. In the morning, the liquidity team adds the expected receipts, such as incoming payments from customers, maturing loans, and FX settlements, and the expected payments, such as outgoing customer payments, loan repayments, and settlement obligations. They use historical patterns to estimate the timing, because a payment due in the morning is different from a payment due in the afternoon. During the day, they update the forecast in real time, as payments are released, as receipts arrive, and as new instructions come in. They also run stress tests, asking what would happen if a large receipt was delayed, or if a customer sent an unexpected USD 367,574.90 payment. The forecast feeds the funding decision, which is how much to borrow from the central bank, how much to move from a nostro account, and how much to keep as a buffer. Good forecasting means payments settle on time, the bank does not pay unnecessary overdraft interest, and it does not breach its intraday limits.

A liquidity buffer is a reserve of high quality, easily available funds that a bank holds to meet unexpected payments or a delay in expected receipts, without having to borrow at short notice or delay its own payments. The buffer is usually held in central bank reserves, in government bonds that can be sold quickly, or in cash in a nostro account with a trusted correspondent. The size of the buffer is set by the bank risk policy, and it is based on the size and volatility of its payment flows, its regulatory requirements, and its stress test results. A bank that processes large, unpredictable payments, such as a USD 367,574.90 corporate payment that could arrive at any time, needs a larger buffer than a bank with small, predictable retail flows. The buffer is not idle money. It is working capital that lets the bank settle payments on time even when a receipt is late, a system is slow, or a market is stressed. Regulators require banks to hold a liquidity coverage ratio buffer, which must cover 30 days of stressed outflows, and an intraday buffer, which must cover the largest intraday shortfall. The buffer is monitored daily, and if it falls below the minimum, the bank must act at once, by borrowing, by selling assets, or by delaying non urgent payments. Holding a buffer costs money, because the funds earn little interest, but not holding one costs more, because a failed payment damages trust and can trigger a regulatory breach.

The central bank acts as lender of last resort by lending money to banks that cannot borrow from anyone else, usually in a crisis, to stop a liquidity problem from becoming a solvency problem and to keep the payment system working. In normal times, banks borrow from each other in the interbank market, or from the central bank through regular operations, such as a repo or a standing facility. In a crisis, when other banks stop lending because they fear the borrower may fail, the central bank steps in and lends against good collateral, usually government bonds, at a penalty rate. The classic rule, set out by Walter Bagehot in the 19th century, is to lend freely, at a high rate, against good collateral, to solvent banks that are short of liquidity. The central bank does this to prevent a bank that is sound in the long term from failing because it cannot meet its payments today, and to stop panic spreading to other banks. The role is important for settlement, because a bank that cannot borrow intraday cannot settle its RTGS payments, and its failure to settle can cause a gridlock that affects the whole system. Central banks therefore offer intraday credit, usually free and against collateral, and overnight lending, at a penalty rate, to keep payments flowing. The lender of last resort is a safety net, not a subsidy, and banks that use it face scrutiny from their supervisor.

A daylight overdraft is an intraday overdraft, where a bank account at the central bank goes negative during the day, because the bank has sent more payments than it has received so far, and it is covered later the same day when receipts arrive. The term daylight is used because the overdraft exists only during the business day, and it must be repaid before the end of the day. Central banks allow daylight overdrafts to help banks settle RTGS payments smoothly, because without them, a bank would need to hold the full amount of every payment in advance, which would be very expensive. In the United States, the Federal Reserve allows daylight overdrafts up to a cap based on the bank capital, and it charges a fee for the amount used. In Europe, the European Central Bank provides intraday credit free of charge, provided the bank posts eligible collateral. A daylight overdraft is not the same as an overnight overdraft, which is a loan that lasts beyond the end of the day and carries a penalty rate. Banks manage daylight overdrafts by forecasting their intraday flows, by timing their payments to match their receipts, and by using liquidity saving mechanisms. A bank that relies on large daylight overdrafts every day may be asked by its supervisor to improve its liquidity management, because a heavy reliance on intraday credit can hide a deeper funding problem.

The Basel intraday liquidity monitoring framework is a set of tools published by the Basel Committee on Banking Supervision in 2013, to help banks and supervisors monitor how much liquidity a bank needs during the day to settle its payments, and whether it has enough. Before the framework, most liquidity rules looked only at end of day balances, which missed the risk that a bank could run out of money in the middle of the day, even if it ended the day with a positive balance. The framework requires large banks to report seven monitoring tools every month, including the daily maximum intraday liquidity usage, the available intraday liquidity at the start of the day, the time specific obligations, the value of payments made, and the intraday throughput. Supervisors use these tools to see whether a bank relies too much on intraday credit, whether its payments are concentrated at certain times, and whether it could cope if a large receipt was delayed. Banks use the same data internally to set intraday limits, to plan their funding, and to spot patterns, such as a regular shortfall at 11:00 when many payments are released. The framework does not set a minimum ratio like the liquidity coverage ratio, but it creates transparency, and supervisors can require a bank to hold more liquidity or to change its payment timing if the monitoring shows a risk. For payments teams, the framework means intraday liquidity is now a board level issue, not just an operations problem.

Herstatt risk is settlement risk in foreign exchange, named after Bankhaus Herstatt, a small German bank that failed on 26 June 1974, and caused losses around the world. Herstatt had taken in US dollars from counterparties in New York, in exchange for German marks it was due to pay in Frankfurt later the same day. At 15:30 German time, the German regulator closed the bank, after its dollar receipts had arrived but before it had paid out the marks. The counterparties had paid dollars and received nothing, losing about USD 620 million in total. The failure showed that in FX settlement, the two legs of a trade settle at different times, in different time zones, through different systems, so one side can pay and the other side can fail before paying back. This time gap is Herstatt risk, also called FX settlement risk. It is not a theoretical risk. It is the risk that a bank pays away one currency and never receives the other currency, because its counterparty fails in between. After Herstatt, regulators created the Basel Committee, improved settlement systems, and encouraged payment versus payment, where both legs settle at the same time or not at all. The CLS system, launched in 2002, was built specifically to remove Herstatt risk. Even today, every FX trader and payments professional learns the Herstatt case, because it explains why settlement timing, not just credit quality, matters.

CLS, or Continuous Linked Settlement, is a payment versus payment system that settles foreign exchange trades in 18 major currencies, and it was built to remove Herstatt risk. When two banks agree an FX trade, for example selling euros and buying US dollars, they submit the trade to CLS. CLS holds both legs of the trade, and it settles them simultaneously, on a payment versus payment basis, meaning either both legs settle at the same time, or neither settles. This removes the risk that one bank pays its currency and the other bank fails before paying the other currency. CLS settles through accounts at the central banks of each currency, so settlement is in central bank money, which is the safest form. It also nets trades, so a bank that has many trades in the same currency settles only its net position with CLS, which reduces liquidity needs. For example, a bank that must pay USD 367,574.90 and receive USD 300,000 in different trades would settle only the net USD 67,574.90 with CLS, not both gross amounts. CLS is owned by its member banks and supervised by the Federal Reserve, and it settles about USD 6 trillion a day, which is more than half of all global FX trading. Banks that use CLS still face credit risk on the trade itself, and they must fund their CLS account on time, but they no longer face the risk of paying away one currency and receiving nothing in return, which was the Herstatt problem.

The Financial Action Task Force, or FATF, is an intergovernmental body founded in 1989 by the G7 to set global standards for combating money laundering, terrorist financing, and the financing of weapons of mass destruction. It has 40 member jurisdictions and its standards are adopted by more than 200 countries through regional bodies. The FATF issues 40 Recommendations that form the backbone of national AML and counter-terrorist financing laws. These cover criminalizing money laundering, customer due diligence, record keeping, reporting suspicious transactions, regulation of financial institutions and designated non-financial businesses, international cooperation, and targeted financial sanctions. The recommendations are risk based, meaning countries and institutions should focus resources where risks are highest. The FATF also maintains grey and black lists of jurisdictions with strategic deficiencies. Being grey listed, as Pakistan was for several years, can raise the cost of correspondent banking and deter foreign investment. For payments professionals, the FATF matters because every bank's screening, monitoring, and reporting regime traces back to these recommendations, and cross-border payment flows are shaped by how different countries implement them.

The EU Anti-Money Laundering Directives are a series of laws that harmonize how member states fight money laundering and terrorist financing. The sixth directive, 6AMLD, took effect in 2021, and a major reform package adopted in 2024 created a single EU rulebook and a new supervisor, the Anti-Money Laundering Authority (AMLA), based in Frankfurt. The directives require obliged entities such as banks, payment institutions, and crypto firms to perform customer due diligence, identify beneficial owners, monitor transactions, report suspicious activity to national financial intelligence units, and keep records for at least five years. They define who counts as a politically exposed person, set rules for high-risk third countries, and require registers of beneficial ownership. The 2024 package also caps large cash payments at 10,000 euros across the EU. For payments teams, the directives drive real work: onboarding flows must collect ownership data, screening must cover EU consolidated lists, and payment messages must carry complete payer and payee information under the accompanying Funds Transfer Regulation. Non-compliance can lead to fines of millions of euros and, since 6AMLD, personal liability for senior managers.

The Bank Secrecy Act, or BSA, is the foundational US anti-money laundering law, enacted in 1970. Despite its name, it is not about secrecy but about transparency: it requires financial institutions to keep records and file reports that help the government detect and prevent money laundering, terrorist financing, and tax evasion. Its key requirements include filing Currency Transaction Reports for cash transactions over 10,000 dollars, filing Suspicious Activity Reports when transactions appear suspicious, maintaining a written AML compliance program with a designated compliance officer, training staff, and independent testing. The BSA also underpins the customer identification program rule, which requires banks to verify the identity of anyone opening an account, and the customer due diligence rule, which requires identifying beneficial owners of legal entity customers. Enforcement is led by FinCEN, the Financial Crimes Enforcement Network, with penalties ranging from large civil fines to criminal prosecution. For payments, the BSA affects everything from cash handling at branches to wire transfer record keeping under the Travel Rule, and it is why US banks ask so many questions about the purpose of large or unusual payments.

A Suspicious Activity Report, or SAR, is a confidential report that a financial institution files with its national financial intelligence unit when it detects activity that may indicate money laundering, terrorist financing, fraud, or another crime. In the US, SARs go to FinCEN; in the UK, they are called SARs too but filed with the National Crime Agency; in the EU, they are usually called Suspicious Transaction Reports. Banks must file a SAR when a transaction has no apparent lawful purpose, involves funds derived from illegal activity, is designed to evade reporting requirements, or has no reasonable business explanation. In the US, the filing deadline is 30 days from detection, extendable to 60 days if no suspect is identified. Critically, the existence of a SAR is strictly confidential: the bank may not tell the customer, a practice known as no tipping off. SARs do not block the transaction by themselves, but they trigger law enforcement analysis, and patterns across many SARs have led to major investigations. For payments teams, transaction monitoring alerts that cannot be cleared as legitimate often end as SARs, so good alert documentation directly supports the quality of the filing.

A Currency Transaction Report, or CTR, is a report filed when a financial institution handles a cash transaction, or several related cash transactions, exceeding 10,000 dollars in a single business day. In the US, CTRs are filed with FinCEN under the Bank Secrecy Act, and the requirement covers deposits, withdrawals, currency exchanges, and other transfers of physical cash. The report captures the identity of the person conducting the transaction, the person on whose behalf it is conducted, and the amounts involved. The 10,000 dollar threshold has not changed since 1970, so inflation has made it catch far more ordinary activity than originally intended. CTRs are routine and are not an accusation of wrongdoing: millions are filed each year and most relate to legitimate business cash. However, the data is powerful for law enforcement because it reveals cash movement patterns. Structuring, deliberately splitting cash transactions to stay below the threshold, is itself a federal crime, and banks use aggregation logic to detect it. Similar thresholds exist elsewhere: the EU requires reporting of cash payments above 10,000 euros under its 2024 AML package, and India requires reporting of cash transactions above 10 lakh rupees to its Financial Intelligence Unit.

Customer Due Diligence, or CDD, is the standard set of checks a financial institution performs to know its customer: verifying identity, understanding the nature of the business relationship, and identifying beneficial owners. CDD is performed at onboarding and refreshed periodically based on risk. Enhanced Due Diligence, or EDD, is a deeper set of checks applied when the customer or the relationship presents higher risk. Triggers for EDD include politically exposed persons, customers from high-risk jurisdictions, correspondent banking relationships, complex ownership structures, and businesses in high-risk sectors such as money services or crypto. EDD goes further: it may require source of wealth and source of funds evidence, senior management approval to onboard, more frequent transaction monitoring, and sometimes site visits or adverse media searches. The distinction is central to the risk-based approach required by the FATF and EU directives: low-risk customers get simplified due diligence, standard customers get CDD, and high-risk customers get EDD. For payments BAs, the difference shows up in onboarding workflows, where risk scoring must route customers to the right diligence path, and in screening rules that apply tighter monitoring to EDD customers.

A beneficial owner is the natural person who ultimately owns or controls a legal entity such as a company, trust, or partnership, even if the ownership is held through layers of other companies. Regulators generally define this as anyone holding 25 percent or more of shares or voting rights, or anyone who otherwise exercises control, for example by appointing the board. Identifying beneficial owners is a core part of customer due diligence because criminals hide behind shell companies to launder money and evade sanctions. The challenge is that ownership can be deliberately obscured through nominee directors, bearer shares, and chains of companies across several jurisdictions. The EU requires member states to maintain central registers of beneficial ownership, the UK has its Persons with Significant Control register, and the US Corporate Transparency Act requires most companies to report beneficial owners to FinCEN. For payments, beneficial ownership matters at onboarding, when a corporate customer must declare its owners, and in screening, where a sanctioned individual who secretly controls a company can make its payments sanctionable. BAs designing onboarding journeys must handle complex ownership trees, document collection, and the awkward reality that legitimate companies sometimes struggle to produce this information quickly.

A Politically Exposed Person, or PEP, is someone who holds or has held a prominent public function, such as a head of state, senior politician, senior judge, senior military officer, or board member of a state-owned enterprise. Family members and close associates of such people are also treated as PEPs. The concept exists because people in powerful positions can be exposed to bribery and corruption, and may use the financial system to move the proceeds. Banks must apply enhanced due diligence to PEPs: senior management approval before onboarding, establishing source of wealth and source of funds, and enhanced ongoing monitoring. Foreign PEPs are always high risk, while domestic PEPs are treated as high risk on a risk-sensitive basis. PEP status is not permanent: in the EU, a person generally stops being a PEP one year after leaving office, though banks may still apply caution. A common pitfall is false positives, since PEP databases contain millions of names including local councillors and minor officials, so screening must be tuned to the bank's risk appetite. For payments, PEP status affects onboarding decisions, transaction monitoring sensitivity, and sometimes whether a payment can proceed without additional approval.

A typology in AML is a documented pattern or method that criminals use to launder money or finance terrorism. Typologies describe the techniques, the types of accounts and products involved, and the red flags that help institutions detect them. Examples include trade-based money laundering, where invoices are manipulated to move value across borders; the use of shell companies to obscure ownership; smurfing, where large sums are split into small deposits; and the misuse of money service businesses. Typologies are published by the FATF, national financial intelligence units, and industry bodies, and banks use them to design transaction monitoring scenarios and train analysts. For instance, a typology on human trafficking might list red flags such as frequent hotel payments, multiple individuals using the same address, and third-party deposits. When a new typology emerges, for example around crypto mixers or COVID relief fraud, banks update their monitoring rules and risk assessments. For payments BAs, typologies are practical tools: they explain why a monitoring scenario exists, what behavior it targets, and what evidence an analyst should look for. A monitoring rule without a typology behind it is just a threshold; with one, it is a reasoned control.

Trade-based money laundering, or TBML, is the use of international trade transactions to disguise the origin of illicit funds and move value across borders. Criminals manipulate trade documents so that the payment for goods does not match their real value or quantity. Common techniques include over-invoicing, where goods are invoiced above their true value so excess money moves abroad; under-invoicing, where the difference stays with the importer; multiple invoicing, where the same shipment is invoiced several times; and phantom shipments, where payment is made for goods that never existed. TBML is estimated to be one of the largest money laundering methods in the world because trade volumes are enormous and documentation is complex. Detection relies on comparing invoice prices against market prices, checking that shipping documents match the goods, and spotting patterns such as round-tripping or payments to unrelated third parties. Banks involved in trade finance and open account payments have a responsibility to screen trade documents and monitor for anomalies. For payments professionals, TBML matters because the payment leg of a trade transaction is often the only part the bank sees, so payment data must be checked against trade data, and dual-use goods or sanctioned countries in the trade chain can create additional sanctions risk.

Structuring, also called smurfing, is the practice of breaking a large sum of money into smaller transactions to avoid a reporting threshold, such as the 10,000 dollar limit that triggers a Currency Transaction Report. The term smurfing comes from the use of multiple people, or smurfs, each making small deposits into different accounts. For example, a criminal with 90,000 dollars in cash might deposit 9,000 dollars at ten different branches over several days. Structuring is itself a federal crime in the US and many other countries, even if the underlying money is legitimate: the act of evading the reporting requirement is the offense. Banks detect structuring through aggregation logic that links transactions by customer, account, and beneficiary across branches and channels, and through monitoring scenarios that flag patterns such as just-below-threshold amounts or frequent cash deposits. Once detected, structuring typically leads to a suspicious activity report. For payments teams, the challenge is that structuring can also occur in non-cash payments, such as splitting a large wire into several smaller ones, so monitoring must cover all channels. Analysts must distinguish genuine business behavior, such as a retailer depositing daily takings, from deliberate evasion, which requires understanding the customer's normal pattern.

A mule account is a bank account used to receive and forward illicit funds on behalf of criminals, often without the account holder fully understanding what they are doing. Money mules are recruited through fake job adverts, social media, or romance scams, and are told they are working as payment processors or mystery shoppers. The criminal sends stolen or laundered money into the mule's account, and the mule forwards it, usually by wire transfer or crypto, keeping a small commission. Mules are a critical link in fraud and money laundering chains: they distance the criminal from the crime and make the funds harder to trace. Banks detect mule accounts through behavioral signals such as a dormant account suddenly receiving large credits followed by rapid onward transfers, or an account whose activity does not match the holder's profile, for example a student receiving multiple high-value payments from unrelated senders. The UK estimates tens of thousands of mule accounts are active, and being a mule can lead to account closure, a fraud marker that blocks future banking, and criminal prosecution. For payments teams, mule detection combines fraud monitoring, transaction monitoring, and information sharing across banks, and it is a growing focus because APP fraud and other scams depend on mule networks to cash out.

A risk-based approach means a financial institution focuses its anti-money laundering effort where the risk of money laundering and terrorist financing is highest, rather than applying the same checks to every customer and transaction. It is the core principle of the FATF Recommendations and the EU AML directives. In practice, the bank first assesses its risks: which customer types, products, channels, and geographies carry the most exposure. A low-risk domestic retail customer gets simplified due diligence, while a high-risk customer, such as a politically exposed person or a money service business, gets enhanced due diligence and closer monitoring. The same logic applies to transaction monitoring, where thresholds and scenarios are tuned to the risk profile of each customer segment. The risk-based approach requires a documented enterprise-wide risk assessment, refreshed regularly, and evidence that controls match the risks identified. Regulators test this: they ask whether the bank understands its risks and whether its controls are proportionate. The danger is using risk-based as an excuse for weak controls, so banks must show their reasoning and keep records. For payments BAs, the risk-based approach shapes onboarding journeys, screening rules, monitoring thresholds, and the design of risk scoring models that drive these decisions.

Adverse media screening is the process of searching news and public sources for negative information about a customer, such as involvement in crime, corruption, fraud, sanctions, or regulatory enforcement. It is a key part of enhanced due diligence and ongoing monitoring, required by the FATF and EU AML directives for higher-risk customers. Screening tools scan thousands of news sources, court records, regulatory releases, and watchlists, matching articles to customer names and flagging relevant hits. The hard part is relevance and accuracy: a common name can return hundreds of irrelevant articles, and a single news story may be unproven allegation rather than fact. Analysts must decide whether the media is credible, recent, and genuinely about the customer, and whether it changes the risk rating. Adverse media screening is also used at onboarding for high-risk customers and in periodic reviews. For payments teams, a strong adverse media hit can lead to declining a customer, exiting a relationship, or increasing monitoring. BAs building onboarding and screening workflows need to design for the triage step: how hits are presented, what evidence is captured, and how decisions are recorded so the bank can prove its reasoning to a regulator.

Customer screening checks the people and companies a bank deals with, while transaction screening checks the individual payments flowing through the bank. Customer screening happens at onboarding and on an ongoing basis: the customer's name is matched against sanctions lists, PEP lists, and adverse media, and the result determines whether the relationship can start and how it is monitored. Transaction screening happens in real time or near real time on every payment: the payer, payee, and payment details are checked against sanctions lists before the funds move. The two are complementary. A customer may be clean at onboarding but later appear on a sanctions list, which ongoing customer screening catches. Conversely, a clean customer can send a payment to a sanctioned beneficiary, which only transaction screening catches. Transaction screening must be fast because payments cannot wait: SWIFT gpi and instant payments create pressure to screen in milliseconds. Customer screening is slower and deeper, involving document checks and ownership analysis. Regulators expect both. A bank that only screens customers will miss sanctioned payments, and a bank that only screens transactions will miss the risk of who it is doing business with. BAs must design both flows and the data sharing between them.

Fuzzy matching is the technique screening systems use to catch names that do not match a sanctions list exactly. Sanctioned individuals and entities appear in payment messages with spelling variations, transliteration differences, missing middle names, reversed name order, or deliberate misspellings designed to evade detection. Exact matching would miss all of these, so fuzzy matching algorithms score how similar two names are using techniques such as edit distance, phonetic matching, and nickname tables. For example, Mohammed, Mohamed, Muhammad, and Mohammad are all variations of the same name, and a good system treats them as near matches. The system assigns a similarity score, and matches above a threshold generate an alert for human review. The challenge is tuning: a threshold set too low creates thousands of false positives that overwhelm analysts, while a threshold set too high lets real matches slip through as false negatives. Regulators, including OFAC, expect banks to use fuzzy matching and have fined institutions that relied on exact matching alone. For BAs, fuzzy matching affects alert volumes, analyst workload, and the design of screening rules for different alphabets and languages.

A payment filter is the screening mechanism that checks payment messages against sanctions lists and internal watchlists before the payment is released. In a payment hub or SWIFT environment, the filter sits between message receipt and execution: it scans fields such as the payer and payee names, account numbers, addresses, and the payment narrative for matches against sanctions lists. Filters use fuzzy matching to catch spelling variations and can apply rules based on country, currency, and keywords, for example flagging payments that mention embargoed goods. When a payment matches, the filter stops it and creates an alert for an analyst to review. Filters operate in real time for instant payments and in near real time for batch and SWIFT traffic, so performance is critical: a slow filter delays payments and breaches service level agreements. The filter must also handle the difference between blocking and rejecting, route alerts to the right team, and keep an audit trail for regulators. Modern filters are increasingly augmented with machine learning to reduce false positives. For BAs, payment filter requirements cover message parsing, field coverage, matching thresholds, alert routing, and the handling of stopped payments, including release, repair, or escalation.

A false negative in screening is a real sanctions or fraud match that the system fails to detect, so a prohibited payment or a criminal customer slips through. It is the opposite of a false positive, where a legitimate payment is wrongly flagged. False negatives are far more dangerous than false positives because they are invisible: nobody notices the missed match unless a regulator, auditor, or law enforcement agency finds it later. The causes include matching thresholds set too high, lists that are out of date, fields that are not screened, such as the payment narrative or intermediary names, and data quality problems like truncated names. The consequences can be severe: OFAC and other regulators have imposed fines of hundreds of millions of dollars for systematic screening failures, and a missed terrorist financing payment can have consequences far beyond fines. Banks manage false negative risk through regular testing, including back-testing screening against known sanctioned names, tuning thresholds, screening all relevant message fields, and independent validation of the screening system. For BAs, the lesson is that screening design must balance efficiency against safety: reducing false positives is good for operations, but never at the cost of creating false negatives.

A sanctions screening alert workflow is the end-to-end process for handling a payment or customer that matches a sanctions list. It starts when the screening engine generates an alert with a match score, the matched list entry, and the payment or customer details. The alert enters a queue where a first-line analyst reviews it: they compare identifiers such as date of birth, address, and nationality to decide whether it is a true match or a false positive. If it is a false positive, they document the reasoning and release the payment. If it is a potential true match, they escalate to a second-line sanctions team, which may contact the customer for more information, consult legal and compliance, and decide whether to block or reject the payment. True matches lead to blocking or rejection, regulatory reporting, and possibly a suspicious activity report. The workflow must be fast because payments are time sensitive, yet thorough because a wrong decision can be a regulatory breach. Good workflow design includes service level agreements, four-eyes checks for high-risk decisions, complete audit trails, and management information on alert volumes and ageing. BAs design these workflows in tools such as Fircosoft, Actimize, or in-house case management systems, covering queue routing, disposition codes, and escalation paths.

A sanctions list is an official register of individuals, companies, vessels, and sometimes whole countries that are subject to restrictive measures such as asset freezes and prohibitions on doing business. The most important lists include the OFAC SDN List, published by the US Treasury, which names specially designated nationals such as terrorists, drug traffickers, and officials of sanctioned regimes. The UN Security Council maintains consolidated lists under resolutions on terrorism and weapons proliferation. The EU Consolidated List combines all EU sanctions designations. The UK has its own consolidated list maintained by OFSI, and other countries maintain theirs. Lists change constantly: names are added, removed, or amended, sometimes daily, and banks must update their screening systems promptly. Each list has different legal force depending on where the bank operates: a bank in the EU must comply with EU sanctions, while a bank processing US dollar payments must also comply with OFAC because US dollar clearing touches the US. Lists contain identifiers such as dates of birth, addresses, and passport numbers that help analysts distinguish a true match from someone with a similar name. Screening systems load all applicable lists and check every customer and payment against them.

Comprehensive sanctions target an entire country or territory, prohibiting almost all trade and financial dealings with it, while list-based sanctions target specific named individuals, entities, or sectors. Comprehensive sanctions apply to countries such as North Korea, Syria, and Cuba under US law, and to regions such as Crimea. Under a comprehensive regime, a bank must block or reject nearly any payment involving that jurisdiction, with only narrow humanitarian exceptions. List-based sanctions, by contrast, name specific people and organizations, such as the individuals on the OFAC SDN list or entities linked to a particular regime, and only dealings with those named parties are prohibited. Most modern sanctions are list-based because they are more targeted and cause less harm to ordinary citizens. The distinction matters operationally: comprehensive sanctions are enforced largely through country and currency screening, while list-based sanctions depend on name matching against lists. Some regimes are hybrids, such as sectoral sanctions on Russia, which restrict specific activities like new debt or energy projects rather than banning everything. For payments teams, the type of sanctions determines the screening logic: comprehensive regimes need geographic blocking rules, while list-based regimes need precise name matching and alert handling.

Secondary sanctions are US measures that penalize non-US persons for doing business with a sanctioned party, even when the activity has no direct connection to the United States. Unlike primary sanctions, which apply to US persons, secondary sanctions use the threat of losing access to the US financial system to force foreign banks and companies to comply with US policy. The most prominent example is US sanctions on Iran: a European or Asian bank that processes payments for an Iranian entity risks being cut off from US dollar clearing or being designated itself. This creates a difficult choice for non-US banks, which must weigh compliance with US sanctions against their own countries' laws, including EU blocking statutes that prohibit compliance with certain US sanctions. Secondary sanctions risk affects correspondent banking, trade finance, and cross-border payments: banks often exit entire customer segments or jurisdictions, a practice called de-risking, rather than manage the exposure. For payments professionals, the practical impact is that a payment with no US party at all can still be blocked because the bank fears secondary sanctions. Understanding this risk is essential when designing payment corridors, choosing correspondent banks, and advising clients on high-risk jurisdictions.

A blocked transaction is one that a bank freezes because it involves a sanctioned party or jurisdiction: the funds are held in a blocked account and cannot be released without a license from the sanctions authority, such as OFAC. Blocking applies when there is a property interest of a sanctioned person, for example when a payment is destined for an SDN. The bank must hold the funds, report the blocking to the regulator, usually within 10 business days, and wait for instructions. A rejected transaction, by contrast, is simply refused and the funds are returned to the sender. Rejection applies when there is no property interest to freeze, for example when a payment is being processed as an intermediary and the bank has no relationship with the sanctioned party, or when a transaction would violate sanctions but no blocked property is involved. The distinction has real consequences: blocked funds can sit frozen for years, while rejected funds go back to the originator quickly. Banks must get this right because incorrectly rejecting a transaction that should have been blocked can be a violation, and incorrectly blocking a transaction that should have been rejected harms the customer. Screening systems encode this logic, and operations teams need clear procedures and training to apply it correctly.

Transaction monitoring and fraud monitoring both watch payments for suspicious behavior, but they have different purposes, rules, and outcomes. Transaction monitoring is an AML control: it looks for patterns that suggest money laundering or terrorist financing, such as structuring, rapid movement of funds through multiple accounts, or activity inconsistent with the customer's profile. It typically runs after the payment has occurred, analyzing batches of transactions against scenarios and thresholds, and its output is often a suspicious activity report. Fraud monitoring, by contrast, protects the customer and the bank from unauthorized or deceptive transactions: it looks for account takeover, stolen card use, or scams, and it usually runs in real time so a suspicious payment can be stopped before the money leaves. Fraud monitoring uses device data, behavioral signals, and velocity checks, and its output is blocking the payment or contacting the customer. The two functions use different data and teams, but they are increasingly converging: a mule account detected by fraud monitoring may also be a money laundering concern, and an AML alert may reveal a scam victim. BAs working on either side need to understand both, because modern platforms share data, and a payment stopped for fraud can also generate an AML alert.

First-party fraud is committed by the customer themselves, while third-party fraud is committed by someone else using the customer's identity or account. In first-party fraud, a person applies for credit or a loan with the intention of never repaying it, exaggerates their income, or falsely claims a payment was unauthorized to get a refund. Bust-out fraud is a classic example: a customer builds up a good credit history, then maxes out all their cards and disappears. In third-party fraud, a criminal impersonates the victim, for example through identity theft, account takeover, or a stolen card, and the victim is innocent. The distinction matters because the response is different. Third-party fraud victims are usually reimbursed and the bank investigates how the account was compromised. First-party fraud suspects face account closure, debt collection, and fraud markers. Detection differs too: first-party fraud is spotted through application data, credit behavior, and links between applications, while third-party fraud is spotted through device signals, behavioral biometrics, and unusual transaction patterns. For payments, first-party fraud includes false refund claims and friendly fraud on card payments, while third-party fraud includes unauthorized wire transfers after an account takeover. Banks need separate strategies, models, and case handling for each type.

Authorized Push Payment fraud, or APP fraud, is a scam in which the victim is tricked into authorizing a payment to a criminal. Unlike unauthorized fraud, where the criminal moves the money, in APP fraud the victim sends it themselves, believing they are paying a genuine person or business. Common types include impersonation scams, where the criminal pretends to be a bank, the police, or a government agency; invoice scams, where a business is tricked into paying a fake supplier invoice; romance scams; and investment scams promising high returns. APP fraud has grown rapidly with faster payments, because once the victim authorizes an instant payment, the money moves in seconds and is quickly forwarded through mule accounts. Losses in the UK exceeded 450 million pounds in 2023, and similar scams affect every country with real-time payments. The challenge for banks is that the payment itself looks legitimate: the customer authenticated it and intended to send it. Defenses include Confirmation of Payee, warning messages, payment delays for high-risk transfers, and education. For payments professionals, APP fraud is now a central risk: it shapes payment journeys, fraud controls, and reimbursement rules, and it is why banks are adding friction to payments that used to be instant and invisible.

The UK APP fraud reimbursement rule is a mandatory requirement introduced by the Payment Systems Regulator in October 2024 that forces payment service providers to reimburse victims of authorized push payment fraud in most cases. Under the rule, when a customer is tricked into sending money to a scammer, the sending bank and the receiving bank split the cost of reimbursement equally, up to a maximum of 85,000 pounds per claim. The rule covers payments made through Faster Payments and CHAPS, and applies to consumers, micro-enterprises, and small charities. There are exceptions: victims who acted with gross negligence, for example by ignoring clear warnings, may not be reimbursed, and claims must be made within 13 months. Banks must assess claims within five business days and reimburse promptly. The rule has transformed fraud prevention incentives: receiving banks are now financially liable for hosting mule accounts, so they have invested heavily in detecting them, and sending banks have strengthened warnings and delays. It also created a new operational burden: claims handling teams, data sharing between banks, and disputes over liability splits. For payments professionals, the rule is a landmark example of regulation shifting fraud losses from victims to the industry, and similar rules are being considered in other countries.

The Contingent Reimbursement Model, or CRM Code, is a voluntary UK industry code introduced in 2019 that set out when banks should reimburse victims of authorized push payment fraud. It was the predecessor to the mandatory reimbursement rule that took effect in October 2024. Under the CRM Code, banks that signed up committed to reimbursing customers who had been scammed, provided the customer had met a standard of care, for example by not ignoring warnings, and the bank had met its own obligations such as effective warnings and fraud detection. The code also required banks to have clear processes for assessing claims and to consider the vulnerability of the customer. Because it was voluntary, not all banks signed up, and reimbursement rates varied widely: some banks reimbursed most victims while others reimbursed very few, which led to criticism and the move to a mandatory regime. The CRM Code is still relevant because its principles, such as the standard of care, vulnerability, and effective warnings, shaped the mandatory rules and continue to influence how banks design fraud controls and claims processes. For payments professionals, the CRM Code is a case study in how voluntary standards can pave the way for regulation, and its concepts still appear in fraud prevention and customer journey design.

Confirmation of Payee, or CoP, is a name-checking service that verifies the name of the recipient of a payment before the money is sent. When a customer enters a sort code, account number, and payee name, the sending bank checks the name against the name held by the receiving bank. The result is a match, a close match with the correct name suggested, or no match. If there is no match, the customer is warned and can choose whether to proceed. CoP was introduced in the UK in 2020 to reduce misdirected payments and authorized push payment fraud: many scams work because the victim sends money to an account whose name does not match the supposed recipient, for example paying a supposed builder whose account is actually in a different name. CoP is now mandatory for the largest UK banks and payment providers, and similar services exist elsewhere, such as the IBAN name check under the EU Instant Payments Regulation. CoP is not foolproof: scammers can open accounts in names that match their cover story, and some legitimate payees use trading names that differ from their account names. For payments BAs, CoP affects payment journeys, API design, error handling, and customer messaging, because a no-match result must be presented clearly enough to stop a scam without blocking legitimate payments.

Behavioral biometrics is a fraud detection technique that identifies users by how they behave, rather than by what they know or what they own. It analyzes patterns such as typing rhythm, mouse movements, swipe gestures, how a phone is held, and how a user navigates an app or website. Each person has a distinctive pattern, so a fraudster who has stolen a password will still behave differently from the genuine customer: they may type faster, hesitate at unfamiliar screens, or copy and paste credentials instead of typing them. Behavioral biometrics runs continuously in the background, building a profile of the legitimate user and scoring each session for risk. It is particularly powerful for detecting account takeover and social engineering, where the criminal has valid credentials but not the victim's behavior. It also helps with bot detection, since automated scripts move a mouse in straight lines and at inhuman speeds. Privacy is a consideration: behavioral data is personal data under regulations such as GDPR, so banks must be transparent and have a lawful basis. For payments, behavioral biometrics is increasingly used to step up authentication for high-risk payments without adding friction for genuine users, making it a key tool in balancing security with a smooth payment experience.

A reject and a return both stop a payment from reaching the beneficiary, but they happen at different points in the life of the payment, and the distinction matters for operations, for accounting, and for the customer. A reject happens before the payment is booked to the beneficiary account. The receiving bank looks at the instruction, finds a problem, and refuses to process it. A return happens after the payment has already been booked and credited, usually to an internal account, and the bank then sends the funds back. In SWIFT MT103 terms, tag 72 carries /REJT for a reject and /RETN for a return, so the code itself tells the next bank which stage was reached. Take the worked example. A French company at BNP Paribas Paris pays USD 367,574.90 to a Spanish company at Banco Santander Madrid, reference 103REF405775. If Santander finds that the beneficiary account ES6300491800132710387658 does not exist, and it has not booked the funds, it rejects the payment. If it has already booked the funds and only then discovers the account cannot be credited, it returns them. A reject is usually faster and cleaner because no customer account was touched. A return needs a reversal of a booking that already happened, and it may need a manual check. Both need a clear reason code, a clear audit trail, and a message back to the sender so the ordering customer can be told what happened and what to do next.

In an MT103 reject or return flow, the bank that cannot complete the payment sends a new MT103 back toward the sender, and tag 72 in field 72, Sender to Receiver Information, carries the code that explains what happened. The code /REJT means reject. It is used when the payment was not booked, so the funds were never credited to a beneficiary account. The code /RETN means return. It is used when the payment was booked and then had to be sent back. The rest of the message carries the original details, including the original reference, the amount, and the reason for the failure, so the sender can match it to the original instruction. In the worked example, the original MT103 carries reference 103REF405775 for USD 367,574.90 from BNP Paribas Paris, BNPAFRPP, to Banco Santander Madrid, BSCHESMM. If Santander cannot apply the funds, it sends an MT103 back with /REJT or /RETN in tag 72, and the funds travel back through the same correspondent chain. Wells Fargo, PNBPUS3N, and Bank of New York Mellon, IRVTUS3N, may be involved again, depending on the route. The ordering bank must then tell its customer, check whether the details can be corrected, and decide whether to resend the payment with corrected details or to cancel it. The key operational point is to read tag 72 first, because it tells you whether a booking was reversed or whether the payment simply never entered the books. This is the legacy MT103 mechanism, for payments sent before the CBPR+ migration. Since coexistence ended on 22 November 2025, a rejected cross-border payment is reported with a pacs.002 and a returned payment travels as a new pacs.004, as chapter 58 explains.

When a payment is rejected because the beneficiary account does not exist, the receiving bank cannot credit the funds, so it stops the payment and sends it back. The bank first checks the account number in field 59, the beneficiary customer, against its own account records. In the worked example, that is account ES6300491800132710387658 at Banco Santander Madrid. If no such account exists, perhaps because of a typing error, a closed account, or a wrong IBAN, the bank rejects the instruction. It does not guess a similar account, and it does not hold the funds indefinitely in the hope that the account will appear. It returns the funds through the payment chain, with a reason code that explains the failure, and in MT103 terms this is a reject, marked /REJT in tag 72, because the funds were never booked to a customer account. The sender bank, BNP Paribas Paris in the example, must then inform the ordering customer, the French company, that the payment failed and why. The customer must provide the correct account number before the payment can be sent again. The correspondent banks in the chain, Wells Fargo and Bank of New York Mellon, simply pass the returned funds back. The lesson for operations is simple. Account validation before sending saves time, charges, and customer frustration, because a payment sent to a non-existent account will always come back, and each leg of the return can take a day or more.

When a payment is rejected for a sanctions hit, the payment is stopped, the funds are not credited, and the case is handed to the bank compliance team. A sanctions check runs on the names, countries, and details in the payment, including the ordering customer, the beneficiary, and any intermediaries. If a name matches a sanctions list, or a country or party is subject to restrictions, the payment engine flags it and the payment is held. The operations team must not release it on its own. Compliance investigates whether the match is a true hit or a false positive, for example a similar name with different details. If it is a true hit, the payment is rejected and the funds are returned to the sender, unless the law requires the funds to be blocked or frozen, in which case the bank follows the regulator instruction. In the worked example, a USD 367,574.90 payment from BNP Paribas Paris to Banco Santander Madrid would be checked at each bank in the chain, including Wells Fargo and Bank of New York Mellon, because each bank is responsible for its own sanctions screening. A hit at any point stops the chain. The sender must be told that the payment was stopped for compliance reasons, but the bank must be careful about what it discloses, because sanctions rules often limit the detail that can be shared. The payment cannot simply be resent with a slightly different name or a different route. That would be an attempt to evade sanctions, which is a serious offence.

A payment recall is a request by the sending bank to the receiving bank to return funds that have already been sent, usually because of an error, fraud, or a customer request. It is not automatic. The receiving bank must check whether the funds are still available, whether they have already been credited to the beneficiary, and whether the beneficiary agrees to return them. In SWIFT, a recall is often sent as an MT199 or MT299 free format message, or in ISO 20022 as a camt.056, because there is no single dedicated recall message in the classic MT range for a customer payment. A recall can be requested when the payment was sent to the wrong account, when the amount was wrong, when the payment was duplicated, or when the ordering customer was a victim of fraud. Timing matters. If the funds have not yet been credited, a recall is usually simple. If they have been credited and the beneficiary has already withdrawn or spent them, the receiving bank may not be able to recover them, and the recall becomes a claim rather than a simple return. In the worked example, if BNP Paribas Paris discovered that the USD 367,574.90 payment under reference 103REF405775 was sent in error, it would send a recall request to Banco Santander Madrid, through the correspondent chain if needed, and Santander would check account ES6300491800132710387658. A recall is a request, not an order, and the receiving bank must act in good faith and within its local law, but it cannot take money from a customer account without a legal basis.

A recall, a return, a reversal, and a refund all move money back, but they are started by different parties, at different times, and for different reasons, so operations staff must not use the words as if they were the same. A recall is a request from the sending bank to the receiving bank to send funds back after the payment has already gone, usually because of an error or fraud. A return is an action by the receiving bank, which sends the funds back because it cannot apply them, for example because the account does not exist or the payment was rejected. A return can happen without a recall. A reversal is a technical undo of a transaction that has already been booked, often in direct debits, where a pacs.007 message reverses a collection, with reason codes such as AM05, MS02, or MS03. A refund is a repayment to the debtor in a direct debit scheme, under scheme rules, and it has specific deadlines. In SEPA Direct Debit, the debtor can claim a no-questions-asked refund up to 8 weeks after the debit, and a refund for an unauthorised transaction up to 13 months after the debit. In the cross-border example, a return of the USD 367,574.90 payment from Santander to BNPP would be a return, while a request from BNPP to Santander to send the money back after credit would be a recall. The key is to ask three questions. Who started it, when was it started, and under which scheme or rule. The answers tell you which term applies, which message to use, and which deadline controls the case.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If the cover arrives before the announcement in a cover payment, the receiving bank has the money but does not yet have the customer details that tell it who the money is for. In the cover method, the MT103 announcement travels directly from the ordering bank to the beneficiary bank, while the MT202 COV cover travels through the correspondent banks and carries the funds. The announcement gives the beneficiary bank the ordering customer, the beneficiary, the account number, and the reference. The cover gives it the value. When the cover arrives first, the beneficiary bank will normally hold the funds in a suspense or settlement account and wait for the announcement to arrive, because it cannot credit a customer account without knowing which customer and which account to credit. It should not guess, and it should not credit the funds to a general account in the hope that the announcement will follow. If the announcement arrives shortly afterwards, the bank matches the two messages by the UETR, the amount, the value date, and the reference, and then credits the beneficiary. If the announcement never arrives, the bank must investigate, using an MT199 or MT299 to ask the sender for the missing details. In the worked example, the MT202 COV from Bank of New York Mellon to Santander carries the funds, while the MT103 from BNP Paribas Paris carries the details for account ES6300491800132710387658. A mismatch in timing is common, because the two messages travel by different routes, and good operations practice is to match them promptly and to chase a missing announcement the same day.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If the announcement arrives but the cover never arrives, the beneficiary bank knows that a payment is coming, but it has no funds to credit, so it must wait and then investigate. The MT103 announcement tells the beneficiary bank the ordering customer, the beneficiary, the amount, the value date, and the reference, but it does not move money. The money moves with the MT202 COV cover, through the correspondent banks. In the worked example, BNP Paribas Paris sends the MT103 announcement directly to Banco Santander Madrid for USD 367,574.90, reference 103REF405775, for account ES6300491800132710387658, while the cover travels from Wells Fargo to Bank of New York Mellon and then to Santander. If the cover is delayed, held for a sanctions check, stuck in an exception queue at a correspondent, or sent to the wrong account, Santander will have an unmatched announcement. It cannot credit the beneficiary, because there are no funds to credit, and it should not credit from its own funds on the strength of the announcement alone unless its policy and its relationship with the sender allow it. Normally it waits until the value date, then sends an MT199 or MT299 investigation to the sender and to the correspondent banks to ask where the cover is. If the cover has been lost or rejected, the sender must resend it or cancel the payment. The customer must be told that the payment is pending, not that it has arrived, because an announcement alone is not a payment.

When a bank receives an MT103 but has no RMA with the sender, it should not process the payment as normal, because RMA, the Relationship Management Application, is the SWIFT authorisation that controls which message types a bank will accept from another bank. RMA is a filter. A bank sets up an RMA to say that it will accept MT103 messages, or MT202 messages, or other types, from a named counterparty. If no RMA exists, the message may be blocked by SWIFT, or it may arrive but the receiving bank must treat it as unauthorised. The correct action is to stop, check the RMA status, and contact the sender bank to ask it to set up the RMA, or to route the payment through a different bank that does have an RMA. The bank should not simply credit the beneficiary on the basis of an unauthorised message, because it has no agreed settlement arrangement with the sender and no assurance that the funds will follow. In the worked example, BNP Paribas Paris and Banco Santander Madrid need an RMA for MT103, and the correspondent banks, Wells Fargo and Bank of New York Mellon, need RMAs for the MT202 COV messages they exchange. If an RMA is missing, the payment will fail or be delayed, and the ordering customer must be told. The practical lesson is to check RMA status before sending a payment to a new counterparty, and to keep RMA records up to date, because a missing RMA is a common and avoidable cause of a failed payment.

When a payment is stuck in an exception queue, it has failed one or more automated checks in the payment engine and has been held for manual review instead of being processed straight through. The payment engine checks the format, the account details, the sanctions lists, the anti-money laundering rules, the settlement instructions, the currency, the value date, and the available funds. If any check fails, or if the payment needs a human decision, it goes to an exception queue where an operations analyst reviews it. The analyst must look at the reason for the hold, correct the data if possible, release the payment if it is valid, repair it if a field is wrong, or reject it if it cannot be fixed. A payment can sit in an exception queue for hours or days if the queue is not worked promptly, and the customer will not know why the payment has not arrived unless someone tells them. In the worked example, a USD 367,574.90 payment from BNP Paribas Paris to Banco Santander Madrid could be held if the beneficiary account ES6300491800132710387658 does not match the name, if the charges instruction SHA is unclear, or if a sanctions screen produces a possible match. The correspondent banks, Wells Fargo and Bank of New York Mellon, have their own exception queues, so a payment can be held at more than one point in the chain. Good practice is to work exception queues in value date order, to prioritise high value payments, and to tell the customer promptly when a payment is held and what is needed to release it.

A payment investigation is a free format message, MT199 or MT299, that a bank sends to another bank to ask a question about a payment, to chase missing funds, or to give information that does not fit into a structured message. MT199 is used for a general investigation, and MT299 is used for a similar purpose, often in a different context or with a different counterparty, but both are free text messages, so the sender writes the question in plain language. An investigation is used when a payment is missing, when the cover has not arrived, when the announcement and the cover do not match, when the beneficiary has not received the funds, when the UETR cannot be found in a message such as an MT910, or when a recall is requested. In the worked example, if Banco Santander Madrid receives the MT202 COV cover from Bank of New York Mellon but cannot match it to an MT103 announcement from BNP Paribas Paris, it would send an MT199 to BNPP asking for the missing details. If BNPP receives a query from its customer about the USD 367,574.90 payment under reference 103REF405775, it would send an MT199 to Santander and to the correspondents to trace the payment. The UETR, the unique end to end transaction reference, should be quoted in the investigation so every bank can find the same payment. Investigations are slow if they are vague, so a good investigation states the amount, the value date, the reference, the UETR, and the exact question, and it asks for a reply by a specific date.

When the beneficiary bank cannot apply the funds to the beneficiary account, it must hold the funds, investigate, and return them if it cannot resolve the problem. The bank may be unable to apply the funds because the account number is wrong, the account is closed, the account is blocked, the beneficiary name does not match the account, or the currency is not supported by that account. In the worked example, Banco Santander Madrid receives funds for account ES6300491800132710387658, and if that account is closed or the name on the payment does not match the account holder, Santander cannot simply credit a different account. It will place the funds in a suspense account, check its records, and contact the sender bank, BNP Paribas Paris, for corrected details. If the sender provides the correct account number, the bank can apply the funds. If the sender cannot provide correct details, or if the beneficiary cannot be identified, the bank must return the funds to the sender, using an MT103 with /REJT or /RETN in tag 72, depending on whether the funds were booked. The bank must not hold the funds indefinitely, and it must not use them for its own purposes. It must also tell the sender what happened and why, so the ordering customer can correct the instruction and resend the payment. The key principle is that funds must always be either applied to the correct account or returned to the sender, never left in suspense without action.

A duplicate payment is a payment that is sent twice for the same underlying obligation, so the beneficiary receives the money two times when only one payment was intended. Duplicates happen when a payment is resent after a timeout, when an operator clicks send twice, when a system retries a failed message, or when a manual repair creates a second instruction. Banks detect duplicates by checking the reference, the amount, the value date, the ordering customer, and the beneficiary, and by checking the UETR, the unique end to end transaction reference, which should be unique for each payment. If two payments have the same UETR, the same reference 103REF405775, the same amount USD 367,574.90, and the same beneficiary account ES6300491800132710387658, the second one is almost certainly a duplicate. The payment engine should block a duplicate before it is sent, and the receiving bank should flag a duplicate when it arrives. If a duplicate has already been credited, the sending bank must request a recall, and the receiving bank must ask the beneficiary to return the extra funds. The beneficiary is not entitled to keep money paid in error, but the bank cannot simply take it back without the beneficiary agreement or a legal basis. The fix is to stop the duplicate at the source, to use unique references and UETRs, and to have a clear procedure for recalling a duplicate payment promptly, because the longer the extra funds stay with the beneficiary, the harder they are to recover.

When a payment is sent to the wrong account, the outcome depends on whether the account exists, whether it belongs to someone else, and whether the funds have already been credited and withdrawn. If the account number does not exist, the receiving bank will reject the payment and return the funds, as described in the answer on a non-existent account. If the account does exist but belongs to a different person, the receiving bank may credit that person in error, and the sending bank must then request a recall. The receiving bank will contact the account holder and ask for the funds to be returned, but the account holder may have already spent them, in which case recovery becomes a legal matter. In the worked example, if BNP Paribas Paris sent USD 367,574.90 to the wrong account at Banco Santander Madrid instead of ES6300491800132710387658, BNPP would send an MT199 investigation and a recall request to Santander, quoting reference 103REF405775 and the UETR. Santander would check whether the funds are still in the wrong account and whether the holder agrees to return them. The ordering customer, the French company, must be told promptly, and the bank must explain what it is doing to recover the funds. Prevention is better than recovery. Account details should be checked against the beneficiary name, the IBAN should be validated, and the payment should be confirmed with the customer before it is sent, because a payment to the wrong account is one of the hardest errors to fix once the funds have left the bank.

The SEPA recall flow is the process by which the originator bank asks the beneficiary bank to return funds that were sent in error in a SEPA Credit Transfer, and it uses ISO 20022 messages. The originator bank sends a camt.056, which is a payment cancellation request, to the beneficiary bank. The beneficiary bank checks whether the funds are still available and whether the beneficiary agrees to the return, and it replies with a camt.029, which is a resolution of investigation, to say whether the recall was accepted or rejected. If the recall is accepted, the funds are returned with a pacs.004, which is a payment return message. The recall can be requested for reasons such as a duplicate payment, a wrong amount, a wrong beneficiary, or a technical error. It is not a guaranteed refund. If the beneficiary has already spent the funds, or if the beneficiary does not agree, the recall may fail, and the originator must pursue the matter through other means. The SEPA recall flow is different from a SEPA Direct Debit refund, which is a debtor right under scheme rules. In a credit transfer recall, the beneficiary bank acts as an intermediary and needs the beneficiary consent in many cases. The key operational point is speed. A recall sent on the same day, with the correct UETR, amount, and value date, has a much better chance of success than a recall sent days later, after the funds have moved on.

No, receiving an MT103 does not mean the other party has received your payment, and this is one of the most common misunderstandings in cross-border payments. An MT103 is a payment instruction, not a proof of payment. It tells the receiving bank to pay a beneficiary, and it gives the details of the payment, but it does not move money by itself. In the serial method, the MT103 travels from bank to bank, and each bank deducts its charges and passes the instruction on, until it reaches the beneficiary bank. In the cover method, the MT103 is an announcement that travels directly from the ordering bank to the beneficiary bank, while the money travels separately with the MT202 COV cover. In both cases, the beneficiary has not received the money until the beneficiary bank has credited the beneficiary account, and the funds have settled. In the worked example, BNP Paribas Paris sends an MT103 to Banco Santander Madrid for USD 367,574.90, reference 103REF405775. Santander has received an instruction, not the money, until the cover arrives from Bank of New York Mellon and Santander credits account ES6300491800132710387658. The MT910 message from BNY to Santander confirms that the cover funds have been credited to Santander account, but even that does not prove that the beneficiary customer has been credited. Only a statement, a confirmation from the beneficiary bank, or a check with the beneficiary proves receipt. An MT103 proves that a payment was instructed, not that it was completed.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. A beneficiary bank can credit its customer before the cover funds arrive, but only if its policy, its risk appetite, and its relationship with the sender allow it, and it is taking a risk by doing so. In the cover method, the MT103 announcement arrives directly from the ordering bank, while the MT202 COV cover arrives later through the correspondent banks. The announcement tells the beneficiary bank who to pay, how much, and on which value date. If the beneficiary bank trusts the sender, if the amount is within its limits, and if it has a settlement arrangement with the sender, it may credit the beneficiary on the strength of the announcement alone, before the cover settles. This is called credit on announcement, and it gives the beneficiary faster access to the funds. The risk is that the cover never arrives, or arrives for a different amount, and the beneficiary bank has already paid out money it has not received. In the worked example, Banco Santander Madrid could credit account ES6300491800132710387658 for USD 367,574.90, or for the settled amount after charges, on the basis of the MT103 from BNP Paribas Paris, before the cover arrives from Bank of New York Mellon. Most banks do not do this for large amounts, for new counterparties, or for high risk payments. They wait for the cover. The decision depends on the bank policy, the counterparty risk, the amount, and the value date, and it should be documented, not left to an individual operator.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. Whether a bank credits on announcement alone is determined by its internal policy, its risk assessment of the sending bank, the amount of the payment, the currency, the value date, and the strength of its settlement arrangements. A bank will normally credit on announcement only when it has a trusted relationship with the sender, when the sender is a well known bank with a good credit rating, when the amount is within an agreed limit, and when the bank has a clear agreement that the cover will follow. It will not credit on announcement for a large amount from an unknown bank, for a payment that has failed a sanctions check, or for a payment where the announcement and the cover are expected to differ. In the worked example, Banco Santander Madrid receives an MT103 announcement from BNP Paribas Paris for USD 367,574.90, reference 103REF405775. Santander knows BNPP, it has an RMA with BNPP, and it has a settlement account with Bank of New York Mellon, so it may decide to credit account ES6300491800132710387658 on announcement. For a smaller bank, or for a first payment from a new counterparty, Santander would wait for the MT202 COV cover and the MT910 confirmation from BNY before crediting. The bank policy should set clear limits, require approval for large amounts, and state what happens if the cover does not arrive. The customer should also be told that a credit on announcement is a service the bank provides at its own risk, not a right, and that the bank may wait for the cover in some cases.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If the amount in the MT103 announcement does not match the MT202 COV, the beneficiary bank has a mismatch that must be investigated before it credits the beneficiary, because it does not know which amount is correct. In the cover method, the MT103 announcement and the MT202 COV cover should carry the same amount, apart from any charges deducted by correspondent banks. In the worked example, the original amount is USD 367,574.90. Wells Fargo charges USD 20, so the settled amount becomes USD 367,554.90. Bank of New York Mellon charges USD 22, so the final settled amount is USD 367,532.90. The announcement should show the original amount, and the cover should show the settled amount after the first correspondent charges, or the amounts should be reconcilable by the charges reported in field 71F. If the amounts differ by more than the reported charges, or if the charges are not reported, the bank cannot safely credit the beneficiary. It must hold the funds, send an MT199 or MT299 investigation to the sender and to the correspondent banks, and ask for the correct amount and the charges breakdown. It must not guess, and it must not credit the larger amount in the hope that the cover will be topped up. The payment will stay in an exception queue until the mismatch is resolved, and the beneficiary will not receive the funds until the bank is sure of the correct amount.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If the UETR in the announcement does not match the UETR in the cover, the beneficiary bank cannot automatically match the two messages, and the payment will go to an exception queue for manual investigation. The UETR, the unique end to end transaction reference, is the key that links the MT103 announcement and the MT202 COV cover together. It should be the same in both messages, in field 121 of Block 3. In the worked example, the MT103 from BNP Paribas Paris to Banco Santander Madrid and the MT202 COV from Bank of New York Mellon to Santander should carry the same UETR, so Santander can match them by UETR, amount, value date, and reference 103REF405775. If the UETRs differ, it may be because one bank generated a new UETR in error, because the cover was created for a different payment, or because the UETR was mistyped. The bank must not assume that two messages with similar amounts are the same payment. It must send an MT199 or MT299 investigation, quote both UETRs, the amounts, the value dates, and the references, and ask the sender and the correspondents to confirm which UETR is correct. Until the mismatch is resolved, the bank cannot credit the beneficiary safely, because it risks crediting the wrong payment or crediting the same payment twice. The lesson is to check the UETR at each step, and to treat a UETR mismatch as a hard stop, not a minor data error.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If a correspondent bank deducts charges but does not report them in field 71F, the next bank in the chain will see a lower settled amount than it expected, and it will not know why, so the payment will be held for investigation. Field 71F, Sender Charges, is the field in an MT103 where a correspondent bank reports the charges it has deducted, so that the next bank can reconcile the amount it receives against the amount that was originally sent. In the worked example, Wells Fargo charges USD 20, and it reports that charge in field 71F, so the settled amount becomes USD 367,554.90 from the original USD 367,574.90. Bank of New York Mellon charges USD 22, and it also reports that charge, so the final settled amount is USD 367,532.90. If Wells Fargo deducted USD 20 but did not report it, Santander would receive USD 367,554.90 and would not know whether USD 20 was a charge, an error, or a missing amount. It would have to send an MT199 investigation to ask for the charges breakdown, and the payment would be delayed. The charges instruction SHA means shared charges, so the ordering customer pays the sender charges and the beneficiary pays the receiver charges, but the correspondent charges in the middle must still be reported. A bank that deducts charges without reporting them is breaking the SWIFT rules, and repeated failures can lead to complaints and to a loss of trust from counterparties.

If field 52A is missing in a serial MT103 where it should be present, the receiving bank will not know who ordered the payment, and it may reject the payment or hold it for investigation. Field 52A, Ordering Institution, identifies the bank that ordered the payment on behalf of its customer, and it is important in a serial payment because the instruction passes from bank to bank, and each bank needs to know the chain of institutions. In the serial example, the MT103 travels from BNP Paribas Paris through Wells Fargo and Bank of New York Mellon to Banco Santander Madrid, and field 52A helps each bank to identify the ordering institution and to check its sanctions and compliance records. If field 52A is missing, the receiving bank cannot complete its checks, it cannot tell the beneficiary who sent the money, and it cannot trace the payment if there is a problem. It may send the payment to an exception queue, or it may reject it and ask the sender to resend it with field 52A completed. The sender bank should check its MT103 format before sending, and should ensure that field 52A is present when the SWIFT rules require it. A missing field 52A is not a minor formatting error. It is a gap in the audit trail, and it can cause delays, compliance failures, and customer complaints, especially for large payments such as USD 367,574.90 where the ordering institution must be clearly identified.

If field 57A is present in a message where the beneficiary account is held by the receiver, the message contains a field that should not be there, and the receiving bank may be confused about where to send the funds. Field 57A, Account With Institution, identifies the bank where the beneficiary account is held, when that bank is not the receiver of the message. If the beneficiary account is held by the receiver itself, field 57A should be omitted, because the receiver already knows that it holds the account. In the worked example, when Banco Santander Madrid receives the MT103, the beneficiary account ES6300491800132710387658 is held by Santander itself, so the final MT103 to Santander should not carry field 57A pointing to Santander. If field 57A is present and points to the receiver, or to a different bank, the receiver must decide whether to ignore it, to treat it as an error, or to reject the payment. In a serial MT103, fields 56a and 57a are used to show the intermediary and the account with institution, but in a cover MT103, fields 53a and 54a are used instead, and 56a and 57a are never used. A stray field 57A can cause the payment engine to route the funds to the wrong bank, or to hold the payment for manual review. The sender should follow the SWIFT field rules for each message type, and the receiver should validate the fields on receipt and raise an exception if a field is present where it should be absent.

If the MT910 never arrives after the cover was sent, the beneficiary bank has no confirmation that the cover funds have been credited to its account, so it must investigate before it credits the beneficiary. The MT910, Confirmation of Credit, is sent by the correspondent bank to the beneficiary bank to confirm that the cover funds have been credited to the beneficiary bank account. In the worked example, Bank of New York Mellon sends an MT910 to Banco Santander Madrid to confirm that the cover funds have been credited to Santander account, after deducting its USD 22 charge, so the final settled amount is USD 367,532.90. If the MT910 never arrives, Santander does not know whether BNY has credited the funds, whether the cover was delayed, or whether the cover was sent to the wrong account. Santander should not credit the beneficiary on the announcement alone unless its policy allows it. It should send an MT199 or MT299 investigation to BNY, quoting the UETR, the amount, the value date, and reference 103REF405775, and asking BNY to confirm the credit or to resend the MT910. It should also check its own account statement, using an MT940 or MT950, to see whether the funds have arrived even without the MT910. If the funds have arrived, the MT910 may have been lost in transmission, and the bank can proceed. If the funds have not arrived, the cover must be traced through Wells Fargo and BNY until it is found.

The UETR is not in the MT910 because the MT910 message format does not have a field for it, and the SWIFT rules for MT910 do not allow the UETR to be carried in field 72, Sender to Receiver Information, or in any other field. The MT910 is an older message type, designed before the UETR was introduced, and it was never updated to carry the UETR. This creates a reconciliation problem. The beneficiary bank receives an MT910 from the correspondent bank confirming a credit, but it cannot match that credit to the MT103 announcement and the MT202 COV cover by UETR alone, because the MT910 has no UETR to match. In the worked example, Bank of New York Mellon sends an MT910 to Banco Santander Madrid confirming the credit of USD 367,532.90, after its USD 22 charge, but Santander cannot match that MT910 to the original payment by UETR. Instead, it must match by amount, value date, currency, sender, and reference, using the details in the MT910 and in its own account records. If those details are not enough, it must send an MT199 or MT299 investigation to BNY, asking BNY to confirm the UETR for that credit. The workaround is manual and slow, and it is one reason why banks prefer ISO 20022 messages, where the UETR is carried in every message, including the credit confirmation. Until MT910 is replaced, operations teams must reconcile by amount and value date, and must chase missing UETRs by investigation.

If a payment is sent in a currency the beneficiary bank does not support, the beneficiary bank cannot credit the funds to the beneficiary account in that currency, so it must either convert the funds, hold them, or return them. A bank supports only the currencies for which it holds accounts, has settlement arrangements, and can process. If it receives a payment in a currency it does not support, it cannot book the funds to a customer account in that currency. In the worked example, the payment is in USD, and Banco Santander Madrid supports USD, so it can credit account ES6300491800132710387658 in USD or convert to EUR if the account is in EUR. If the payment had been in a currency Santander does not support, Santander would have to decide whether to convert the funds to a supported currency, with the beneficiary agreement, or to return the funds to the sender. Conversion needs a foreign exchange rate, and the beneficiary may not want the funds converted. The sender bank should check before sending whether the beneficiary bank supports the currency, and whether the beneficiary account can hold that currency. If it does not, the sender should either send the payment in a supported currency, or use a different beneficiary bank. A payment in an unsupported currency will be delayed, will incur conversion charges, or will be returned, and the customer will be unhappy. The lesson is to confirm the currency and the account currency before sending, not after the payment has failed.

If the value date in field 32A is a holiday in the settlement country, the payment cannot settle on that date, because the settlement system, the correspondent banks, or the central bank will be closed, so the payment will be delayed to the next business day. Field 32A carries the value date, the currency, and the amount, and the value date is the date on which the funds should be available to the beneficiary. If that date is a holiday in the country where settlement takes place, for example a US holiday for a USD payment, or a Spanish holiday for a payment to Madrid, the payment cannot be processed on that day. The sending bank should check the holiday calendar before it sets the value date, and should set the value date to the next business day. If it does not, the receiving bank will hold the payment until the next business day, and the beneficiary will receive the funds late. In the worked example, the USD 367,574.90 payment from BNP Paribas Paris to Banco Santander Madrid settles through Wells Fargo and Bank of New York Mellon in the United States, so a US holiday would delay the cover, even if the MT103 announcement arrives on time in Madrid. The beneficiary bank should tell the sender that the value date is a holiday, and should agree a new value date. The customer should be told that the payment will arrive a day later, and that no interest will be paid for the delay unless the bank policy provides for it. Holiday calendars are a basic part of payment operations, and they should be checked for every cross-border payment.

If the ordering customer and beneficiary customer are the same entity, the payment is a transfer between two accounts owned by the same company or person, often in different countries or at different banks, and it is still a payment, but it needs extra checks. The bank must check that the payment is genuine, that it is not a way to move funds to evade sanctions, tax, or anti-money laundering rules, and that the purpose of the payment is clear. A company may pay itself to move funds from its French account at BNP Paribas Paris to its Spanish account at Banco Santander Madrid, for example to fund a subsidiary, to pay a supplier from a different entity, or to consolidate cash. The MT103 will show the same name in field 50, the ordering customer, and in field 59, the beneficiary customer, but with different account numbers. The bank should not automatically reject a same entity payment, but it should ask for the purpose, check the source of funds, and ensure that the payment complies with local regulations. In some cases, a same entity payment should be sent as an MT202, a bank to bank payment, or as an MT200, an own account transfer, rather than as an MT103 customer payment, depending on whether the accounts are held by the same bank or by different banks. The key is to understand the business reason, to document it, and to apply the same sanctions and anti-money laundering checks as for any other payment, because a same entity payment can still be used for illicit purposes.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If a bank receives an MT202 COV without an underlying MT103, it has received cover funds but it has no customer payment details to tell it who the funds are for, so it cannot credit a beneficiary. An MT202 COV is a cover payment. It carries the funds for an underlying MT103 customer payment, and it contains the MT103 details in its Sequence B, including the ordering customer, the beneficiary, the account number, and the reference. If a bank receives an MT202 COV that has no Sequence B, or whose Sequence B does not match any MT103 it has received, it must hold the funds and investigate. In the worked example, Bank of New York Mellon sends an MT202 COV to Banco Santander Madrid to cover the USD 367,574.90 payment from BNP Paribas Paris, and the MT202 COV Sequence B should carry the same details as the MT103 announcement, including reference 103REF405775 and beneficiary account ES6300491800132710387658. If Santander receives the MT202 COV but has no MT103, it should send an MT199 or MT299 to BNPP and to BNY, asking for the underlying MT103 details. It should not credit the funds to a general account, and it should not guess the beneficiary. If the MT103 never arrives, the funds must be returned to the sender, because a cover without an underlying customer payment has no lawful beneficiary. The MT202 COV is not a standalone payment. It only makes sense when it is linked to an MT103.

The BNPP payment is the pre-migration worked example from chapter 5, so its messages are MT103s and MT202 COVs. The same payment today travels as pacs.008 and pacs.009 COV messages. If the MT202 COV Sequence B does not match the MT103 announcement exactly, the beneficiary bank has a mismatch that must be resolved before it credits the beneficiary, because it cannot be sure that the cover and the announcement relate to the same payment. Sequence B in an MT202 COV carries the underlying MT103 details, including the ordering customer, the beneficiary, the account number, the amount, and the reference. Sequence A carries the cover details, including the sender, the receiver, and the settled amount. In the worked example, Sequence B should match the MT103 from BNP Paribas Paris to Banco Santander Madrid for USD 367,574.90, reference 103REF405775, beneficiary account ES6300491800132710387658. If Sequence B shows a different amount, a different account, a different reference, or a different beneficiary name, the bank must hold the payment and send an MT199 or MT299 investigation to the sender and to the correspondent banks. It must not credit the beneficiary on the basis of Sequence B alone, and it must not credit on the basis of the announcement alone, because the two messages disagree. The mismatch may be a typing error, a truncated field, or a genuine error in the cover. The bank must ask for corrected details, and the sender must resend the correct MT202 COV or the correct MT103. Until the two messages match, the payment stays in an exception queue, and the beneficiary does not receive the funds. Exact matching is the core control in the cover method, and any difference is a hard stop.

MT200 is a SWIFT message used for a bank to bank transfer of funds between two accounts held by the same bank, or for a transfer of funds from one account to another account owned by the same institution. It is an own account transfer. The sending bank instructs the receiving bank to debit one of its accounts and credit another of its accounts, for example to move funds from its account at a correspondent bank to its account at another bank, or to fund its own nostro account. MT200 is not a customer payment. It does not carry a beneficiary customer, and it does not carry the detailed customer information found in an MT103. It is used for treasury, liquidity management, and internal funding. For example, if BNP Paribas Paris needs to move USD from its account at Wells Fargo to its account at Bank of New York Mellon, it could send an MT200 to Wells Fargo instructing it to transfer the funds. The message is simple, it carries the amount, the value date, the debit account, and the credit account, and it is processed as a bank to bank instruction. MT200 is different from MT202, which is a general bank to bank payment that can be used for a payment on behalf of a third party, and from MT202 COV, which is a cover for a customer payment. MT200 is only for the bank own funds, and it should never be used to pay a customer.

MT201 is a SWIFT message used for multiple bank to bank transfers, and it differs from MT200 in that it carries more than one transfer in a single message. MT200 is for a single own account transfer, one debit and one credit, between two accounts owned by the same bank. MT201 is for multiple own account transfers, where the sending bank instructs the receiving bank to make several transfers, each with its own amount, value date, and accounts, in one message. This saves time and reduces the number of messages when a bank needs to move funds to several accounts at once, for example to fund several nostro accounts, or to make several internal transfers on the same day. The structure of MT201 is similar to MT200, but it repeats the transfer details for each transaction, so the receiving bank can process each one separately. The key difference is volume. MT200 is one transfer, MT201 is many transfers in one message. Both are bank to bank messages, both are for the bank own funds, and neither is a customer payment. Neither should be used to pay a customer, and neither carries the beneficiary customer details found in an MT103. In practice, MT201 is less common than MT200, because most banks prefer to send separate MT200 messages for clarity, but MT201 is useful when a bank has a regular batch of internal transfers to make, and it wants to send them as a single instruction.

MT203 is a SWIFT message used for multiple general bank to bank transfers, and it is the multiple version of MT202. MT202 is for a single bank to bank payment, while MT203 carries several bank to bank payments in one message, each with its own amount, value date, sender, and receiver. It is used when a bank needs to make several bank to bank payments at once, for example to settle several transactions with the same correspondent bank, or to make several payments to different banks through the same channel. Each transfer in an MT203 is processed separately by the receiving bank, even though they arrive in one message. MT203 is not a customer payment message. It does not carry beneficiary customer details in the same way as an MT103, although it can be used to settle a customer payment if the underlying customer details are carried elsewhere. It is a bank to bank message, used for treasury, settlement, and interbank payments. In the worked example, if BNP Paribas Paris needed to make several bank to bank payments to Bank of New York Mellon on the same day, it could use an MT203 to send them together, rather than sending several MT202 messages. MT203 is less common than MT202 in daily operations, because most banks prefer single messages for easier reconciliation, but it is a useful tool for batch settlement, and it follows the same field rules as MT202, with repeated blocks for each transfer.

MT210 is a SWIFT message used as a notice to receive, which means it tells a bank that funds are coming, so the bank can expect the credit and can plan its liquidity. The sending bank sends an MT210 to the receiving bank to say that it will send funds on a given value date, for a given amount, in a given currency, and to a given account. The receiving bank does not act on the MT210 to credit a customer. It uses it for information, to forecast its cash position, to check that the funds arrive as expected, and to match the incoming credit when it arrives. A notice to receive is useful when a large payment is expected, when a bank needs to manage its intraday liquidity, or when a payment is sent by a different route and the receiving bank needs advance warning. In the worked example, Bank of New York Mellon could send an MT210 to Banco Santander Madrid to say that it will credit Santander account with USD 367,532.90 on the value date, so Santander can expect the funds and can plan to credit account ES6300491800132710387658 when the cover arrives. The MT210 does not move money. It is only a notice. The actual funds move with an MT202, an MT202 COV, or an MT103, depending on the payment type. If the funds do not arrive as notified, the receiving bank can chase the sender using the MT210 details, and it can ask where the funds are.

MT202 and MT202 COV look similar, but they have different functions, and the field differences tell you which one you are looking at. Functionally, MT202 is a general bank to bank payment. It moves funds from one bank to another, for the bank own account or on behalf of a third party, and it does not need an underlying customer payment. MT202 COV is a cover payment. It moves funds to cover an underlying MT103 customer payment, and it must be linked to that MT103. Field by field, the main difference is in field 21, Related Reference. In a plain MT202, field 21 is Nonref, meaning no reference, or it is empty. In an MT202 COV, field 21 carries the underlying reference, in the worked example 103REF405775, so the receiver can link the cover to the customer payment. The second difference is that an MT202 COV contains the MT103 details in its Sequence B, including the ordering customer, the beneficiary, the account, and the amount, while a plain MT202 has no Sequence B. The third difference is in Block 3, where an MT202 COV carries tag 119, the validation flag, which tells the receiver that the message is a cover and that it must be validated against the underlying MT103. A plain MT202 does not carry tag 119. In the worked example, the cover from Bank of New York Mellon to Santander is an MT202 COV, not a plain MT202, because it covers the MT103 from BNP Paribas Paris to Santander for USD 367,574.90. If you see tag 119 and a Sequence B, it is a cover. If you do not, it is a general bank to bank payment.

Block 3 tag 119 is the validation flag in an MT202 COV, and it is a marker in the user header of the message that tells the receiving bank that this MT202 is a cover payment and that it must be validated against the underlying MT103. Block 3 is the user header of a SWIFT message, and it carries extra routing and validation data that is not part of the business content in Block 4. Tag 119 is specific to MT202 COV, and it is set to indicate that the message is a cover, that it carries Sequence A and Sequence B, and that the receiver should check that Sequence B matches the MT103 announcement it has received. Without tag 119, a receiving bank might treat the message as a plain MT202, a general bank to bank payment, and might credit the funds to the wrong account or fail to link the cover to the customer payment. In the worked example, the MT202 COV from Bank of New York Mellon to Banco Santander Madrid carries tag 119 in Block 3, so Santander knows that this is a cover for the MT103 from BNP Paribas Paris for USD 367,574.90, reference 103REF405775, and that it must match Sequence B to that MT103 before it credits account ES6300491800132710387658. The validation flag is a control, not a business field. It does not carry an amount or an account number. It simply tells the payment engine to apply the cover validation rules, and if the validation fails, the payment goes to an exception queue for manual review.

Sequence A and Sequence B are the two parts of an MT202 COV message, and each carries a different set of details. Sequence A carries the cover details, which are the bank to bank details of the funds transfer itself. It includes the sender, the receiver, the amount, the value date, the charges, and the reference for the cover payment. Sequence B carries the underlying customer payment details, which are copied from the MT103 announcement. It includes the ordering customer, the beneficiary customer, the beneficiary account, the amount, and the reference of the original customer payment. In the worked example, Sequence A of the MT202 COV from Bank of New York Mellon to Banco Santander Madrid shows BNY as the sender, Santander as the receiver, and the settled amount USD 367,532.90 after BNY USD 22 charge. Sequence B shows the original MT103 details, the French company as ordering customer, the Spanish company as beneficiary, account ES6300491800132710387658, original amount USD 367,574.90, and reference 103REF405775. The receiving bank uses Sequence A to book the cover funds to its own account, and it uses Sequence B to match the cover to the MT103 announcement and to credit the beneficiary. If Sequence A and Sequence B do not match the MT103, the payment goes to an exception queue. The two sequences must be read together. Sequence A tells you where the money is, and Sequence B tells you who the money is for.

An MT103 announcement and an MT103 serial are two ways of sending the same customer payment instruction, and they differ in their route and in their fields. In the serial method, a single MT103 travels from bank to bank along the payment chain. Each bank receives the MT103, deducts its charges, and sends a new MT103 to the next bank, until it reaches the beneficiary bank. The instruction and the funds travel together, step by step. In the cover method, the MT103 is an announcement. It travels directly from the ordering bank to the beneficiary bank, with the customer details, while the funds travel separately through the correspondent banks with an MT202 COV cover. The announcement tells the beneficiary bank who to pay, and the cover tells it that the funds are coming. In the worked example, the serial method would send the MT103 from BNP Paribas Paris to Wells Fargo, then to Bank of New York Mellon, then to Banco Santander Madrid, with Wells Fargo charging USD 20 and BNY charging USD 22, so the final settled amount is USD 367,532.90. The cover method sends the MT103 announcement directly from BNPP to Santander, and sends the MT202 COV cover from Wells Fargo to BNY to Santander. The field differences follow the route. A serial MT103 uses fields 56a and 57a, but never 53a and 54a. A cover MT103 uses fields 53a and 54a, but never 56a and 57a. The choice of method depends on the banks, the currency, and the settlement arrangements.

The serial MT103 uses fields 56a and 57a but never 53a and 54a because of the way the payment travels in the serial method, and the fields tell each bank where to send the instruction next. Field 56a, Intermediary Institution, identifies the next bank in the chain, the bank that will receive the MT103 after the current receiver. Field 57a, Account With Institution, identifies the bank where the beneficiary account is held, when that bank is not the receiver. In a serial payment, the MT103 moves step by step, so each bank needs to know the next bank and the final bank. Fields 53a and 54a are not used in a serial MT103, because they belong to the cover method. Field 53a, Sender Correspondent, and field 54a, Receiver Correspondent, identify the correspondent banks that will carry the cover funds in a cover payment, and they are only relevant when the instruction and the funds travel separately. In a serial payment, the instruction and the funds travel together, so there is no separate cover to identify, and fields 53a and 54a would be meaningless. In the serial example, the MT103 from BNP Paribas Paris to Wells Fargo would use field 56a to show Bank of New York Mellon as the intermediary, and field 57a to show Banco Santander Madrid as the account with institution, for beneficiary account ES6300491800132710387658. The SWIFT field rules are strict, and a serial MT103 that carries 53a or 54a will be rejected or held for repair, because the fields do not match the method.

The cover MT103 uses fields 53a and 54a but never 56a and 57a because in the cover method the instruction and the funds travel by different routes, and the fields tell the beneficiary bank which correspondent banks will carry the funds. Field 53a, Sender Correspondent, identifies the correspondent bank of the sender, the bank that will send the cover funds. Field 54a, Receiver Correspondent, identifies the correspondent bank of the receiver, the bank that will receive the cover funds on behalf of the beneficiary bank. In the worked example, the cover MT103 announcement from BNP Paribas Paris to Banco Santander Madrid carries field 53a showing Wells Fargo, PNBPUS3N, as the sender correspondent for BNPP, and field 54a showing Bank of New York Mellon, IRVTUS3N, as the receiver correspondent for Santander. This tells Santander that the funds will come from Wells Fargo through BNY. Fields 56a and 57a are not used in a cover MT103, because they belong to the serial method. Field 56a identifies the next bank in a step by step chain, and field 57a identifies the bank where the beneficiary account is held when it is not the receiver, and neither is relevant when the announcement goes directly to the beneficiary bank. A cover MT103 that carries 56a or 57a will be rejected or held, because the fields do not match the method. The rule is simple. Serial uses 56a and 57a, cover uses 53a and 54a, and the two sets are never mixed in the same MT103.

An MT950 is a statement message, and it is sent instead of an MT910 when a bank wants to send a full statement of account, rather than a single confirmation of credit. MT910 is a Confirmation of Credit. It confirms a single credit to an account, for example the cover funds for one payment. MT950 is a Statement Message. It lists all the debits and credits on an account over a period, usually a day, with opening and closing balances. A bank sends an MT950 to its customer, or to another bank, to give a complete record of the account activity, so the receiver can reconcile its books. In the worked example, Bank of New York Mellon sends an MT910 to Banco Santander Madrid to confirm that the cover funds of USD 367,532.90 have been credited to Santander account, after the USD 22 charge. If Santander wants a full statement of its account at BNY for that day, showing all credits and debits, BNY would send an MT950 instead, or as well. MT950 is used for daily reconciliation, for audit, and for checking that all expected credits have arrived. MT910 is used for a single, immediate confirmation, so the beneficiary bank can credit its customer promptly without waiting for the end of day statement. The choice depends on what the receiver needs. A single confirmation for a single payment is an MT910. A full record for a whole day is an MT950.

MT940, MT941, MT942, and MT950 are all account statement and reporting messages, but they differ in timing and in content. MT940 is a Customer Statement Message. It is sent at the end of the day, and it gives the full statement for an account, with all transactions, opening balance, and closing balance. MT941 is a Balance Report. It is sent during the day, on request, and it gives the current balance of an account, without the full transaction details. MT942 is an Interim Transaction Report. It is sent during the day, and it gives the transactions that have happened since the last statement, so the receiver can see intraday activity. MT950 is a Statement Message, similar to MT940, but it is used for a statement sent by a bank to another bank, or for a statement of a nostro account, rather than a customer statement. In ISO 20022 terms, MT940 maps to camt.053, the bank to customer statement, and MT941 and MT942 map to camt.052, the bank to customer account report. In the worked example, Banco Santander Madrid could receive an MT942 during the day to see that the cover funds from Bank of New York Mellon have arrived, an MT941 to check its balance at BNY, and an MT940 or MT950 at the end of the day to reconcile the full account, including the USD 367,532.90 credit. The key is timing. MT941 and MT942 are intraday, MT940 and MT950 are end of day, and MT950 is the bank to bank version of the statement.

SWIFT T copy and Y copy are services that allow a third party, such as a central bank, a regulator, or a market infrastructure, to receive a copy of a payment message for monitoring, for settlement, or for compliance. In a T copy service, the payment message is sent to the third party, and the third party must approve or authorise it before it is forwarded to the receiving bank. The T stands for the third party, and the copy is a condition for the payment to proceed. In a Y copy service, the payment message is sent to the receiving bank and a copy is sent to the third party at the same time, for information or for settlement, but the third party does not block the payment. The Y stands for the shape of the flow, where the message splits into two paths. T copy is used when a central bank needs to approve a payment, or when a payment system needs to settle the funds before the instruction is released. Y copy is used when a regulator or a system needs to see the payment for reporting or for anti-money laundering monitoring, without delaying it. Both services are set up in advance, and the banks involved must agree to them. They are not used for every payment. They are used for specific corridors, currencies, or payment systems where a third party needs visibility or control. Understanding T copy and Y copy helps operations staff to explain why a payment is delayed when a third party approval is needed, or why a copy was sent to a regulator.

RMA, the Relationship Management Application, is a SWIFT service that controls which message types a bank will accept from another bank, and it is a security and authorisation filter. A bank sets up an RMA with a counterparty bank to say that it will accept MT103 messages, MT202 messages, MT202 COV messages, or other types, from that bank. The RMA is set up in advance, and it can be limited to specific message types, or it can be open. Without an RMA, a bank should not accept a payment message from the sender, because it has no agreed relationship and no assurance that the sender is authorised to send that message type. The message may be blocked by SWIFT, or it may arrive but the receiving bank must treat it as unauthorised and must not process it. In the worked example, BNP Paribas Paris and Banco Santander Madrid need an RMA for MT103, and Wells Fargo and Bank of New York Mellon need RMAs for MT202 COV. If any RMA is missing, the payment will fail, be delayed, or be returned, and the ordering customer must be told. The practical lesson is to check RMA status before sending a payment to a new counterparty, and to keep RMA records up to date. RMA is not a formality. It is a control that prevents fraud, prevents unauthorised payments, and ensures that banks only accept messages from counterparties they trust. A missing RMA is a common and avoidable cause of a failed payment, and it should be fixed before the payment is sent, not after it has failed.

A BIC, Bank Identifier Code, is a unique code that identifies a bank or a financial institution in international payments, and it is also known as a SWIFT code. It is structured in three parts, with 8 or 11 characters. The first four characters are the bank code, which identifies the bank. The next two characters are the country code, which identifies the country where the bank is located. The next two characters are the location code, which identifies the city or region. If the BIC has 11 characters, the last three are the branch code, which identifies a specific branch. If the BIC has 8 characters, it identifies the head office. In the worked example, BNPAFRPP is the BIC for BNP Paribas Paris. BNPA is the bank code for BNP Paribas, FR is the country code for France, and PP is the location code for Paris. BSCHESMM is the BIC for Banco Santander Madrid. BSCH is the bank code for Banco Santander, ES is the country code for Spain, and MM is the location code for Madrid. PNBPUS3N is the BIC for Wells Fargo in the United States, and IRVTUS3N is the BIC for Bank of New York Mellon. The BIC is used in field 52A, 53A, 54A, 56A, 57A, and 59, to identify banks in a payment chain. A wrong BIC will send a payment to the wrong bank, or will cause the payment to be rejected, so the BIC must be checked carefully before a payment is sent. The BIC is the address of the bank in the SWIFT network.

In SEPA Direct Debit, SDD, about 70 percent of messages are for exceptions and only 30 percent are for the happy path, because the happy path is simple and needs only a few messages, while the exception path needs many messages to handle all the things that can go wrong. The happy path for an SDD collection is straightforward. The creditor sends a pain.008 direct debit instruction, the debtor bank debits the debtor, and the funds are credited to the creditor. That is only a few messages. The exception path is much more complex. It includes rejects, returns, refunds, reversals, recalls, mandate checks, and investigations, and each exception needs its own message, its own reason code, and its own deadline. A reject happens before settlement, a return happens after settlement, a refund is a debtor right, a reversal is a technical undo, and a recall is a creditor request, and each one uses a different message, such as pacs.002, pacs.004, or pacs.007. The 70 percent figure, from , shows that in real operations most of the work is not in sending the collection, but in handling the cases where the collection fails, is disputed, or needs to be returned. This is why payment operations teams spend most of their time on exceptions, not on happy path processing, and why a good understanding of R-transactions, reason codes, and deadlines is essential for anyone working in SEPA Direct Debit.

The SDD reject flow is the process by which a direct debit collection is rejected before settlement, because it cannot be processed, and it uses ISO 20022 messages. The creditor sends a pain.008 direct debit instruction to its bank, the creditor bank. The creditor bank sends a pacs.003, a direct debit collection, to the debtor bank through the clearing system. If the debtor bank finds a problem, for example the account does not exist, the mandate is invalid, the account is closed, or the debtor bank cannot process the collection, it rejects the collection before settlement. It sends a pacs.002, a payment status report, back to the creditor bank, with a reason code explaining why the collection was rejected. The creditor bank then tells the creditor that the collection failed and why. A reject is different from a return, which happens after settlement, and from a refund, which is a debtor right after the debit. The reject flow is fast, because it happens before the funds move, and the creditor can correct the details and resend the collection if the problem is fixable. Common reject reasons include an invalid IBAN, a missing mandate, a closed account, or a technical error in the pain.008. The key operational point is to read the pacs.002 reason code, to tell the creditor promptly, and to check whether the mandate and the account details are correct before resending, because a collection that is resent without correction will be rejected again.

An SDD return and an SDD refund both move money back to the debtor, but they are started by different parties, for different reasons, and under different rules. An SDD return is started by the debtor bank, after settlement, because the collection cannot be applied or because the debtor bank has a reason to return the funds. For example, the account was closed after the debit, the debtor is deceased, or the bank made an error. The debtor bank sends a pacs.004, a payment return, to the creditor bank, and the funds are returned to the debtor. A refund is started by the debtor, the customer, who claims that the collection was not authorised, or who uses the no-questions-asked right to have the funds returned. In the SEPA Direct Debit Core scheme, the debtor can claim a no-questions-asked refund up to 8 weeks after the debit, and a refund for an unauthorised transaction up to 13 months after the debit. The debtor bank must then return the funds, using a pacs.004, and the creditor bank must debit the creditor. The difference is who initiates it and why. A return is a bank initiated action after settlement, usually for a technical or account reason. A refund is a debtor initiated claim under scheme rules, usually because the debtor disputes the collection. Both use pacs.004 to move the funds, but the reason code and the process are different, and the deadlines are different.

The no-questions-asked refund in SEPA Direct Debit is a right given to the debtor under the SEPA Direct Debit Core scheme, which allows the debtor to have a direct debit collection refunded without having to give a reason, provided the claim is made within 8 weeks of the debit date. The debtor does not need to prove that the collection was wrong, unauthorised, or incorrect. The debtor simply asks the debtor bank for a refund, and the bank must return the funds. This right exists to give consumers confidence in direct debits, because they are allowing a creditor to take money directly from their account. The 8 week deadline is strict. If the debtor claims the refund within 8 weeks of the date the funds were debited, the bank must refund it. If the debtor claims after 8 weeks, the no-questions-asked right no longer applies, and the debtor must use a different route, such as a claim for an unauthorised transaction, which has a 13 month deadline, or a direct dispute with the creditor. The creditor is then debited, and the creditor must pursue the debtor directly if it believes the collection was valid. The no-questions-asked refund does not apply to SDD B2B, the business to business scheme, where the debtor is a business and has no refund rights for authorised collections. The 8 week rule is a key deadline that every operations analyst working in SEPA must know, and it must be explained clearly to debtors who ask for a refund.

The refund for an unauthorised SDD transaction is a right given to the debtor under the SEPA Direct Debit Core scheme, which allows the debtor to claim a refund when a direct debit was taken without a valid mandate, or without authorisation, and the deadline for the claim is 13 months from the debit date. This is different from the no-questions-asked refund, which has an 8 week deadline and needs no reason. An unauthorised transaction refund needs the debtor to claim that the collection was not authorised, for example because there was no mandate, the mandate was invalid, the mandate had been cancelled, or the collection was for a different amount or date than agreed. The debtor bank must investigate the claim, check the mandate, and if the claim is valid, it must refund the debtor. The 13 month deadline is long, because an unauthorised collection may not be noticed immediately, especially if the debtor does not check statements regularly. If the debtor claims within 13 months, the bank must refund. If the debtor claims after 13 months, the right is lost, and the debtor must pursue the creditor directly. The creditor is debited when a refund is paid, and the creditor can dispute the claim if it believes the mandate was valid. The 13 month rule protects consumers from unauthorised debits, and it is a key reason why creditors must keep valid mandates, store them correctly, and ensure that each collection matches the mandate. Without a valid mandate, a creditor has no defence against an unauthorised refund claim.

SDD B2B, the SEPA Direct Debit Business to Business scheme, gives no refund rights for authorised collections because it is designed for businesses, not consumers, and businesses are expected to check their accounts, to manage their mandates, and to resolve disputes directly with the creditor, rather than using a no-questions-asked refund. In the SDD Core scheme, for consumers, the debtor has a no-questions-asked refund right up to 8 weeks, and an unauthorised refund right up to 13 months, because consumers need protection when a creditor can take money directly from their account. In SDD B2B, the debtor is a business, the creditor is a business, and both parties are expected to be sophisticated, to have treasury controls, and to check their bank statements promptly. The B2B scheme therefore removes the refund right for authorised collections, so that a business cannot have a valid collection reversed simply because it changed its mind. The debtor bank must still check that the mandate is valid, and the debtor must still authorise the mandate with its bank before the first collection, but once a collection is authorised, it is final, and the debtor cannot claim a refund under scheme rules. If a business disputes a B2B collection, it must resolve the dispute directly with the creditor, through commercial negotiation or legal action, not through the bank. This makes B2B collections more certain for creditors, but it also means that businesses must be careful about which mandates they sign, and must monitor their accounts closely.

A pacs.007 reversal is an ISO 20022 message used to reverse a payment that has already been settled, in SEPA Direct Debit and in other SEPA schemes, and it carries a reason code that explains why the payment is being reversed. The reversal is sent by the bank that originally sent the payment, or by the clearing system, to undo a transaction that should not have happened. The reason codes AM05, MS02, and MS03 are three common codes used in pacs.007. AM05 means duplication, which is used when the same payment was sent twice, and the second payment must be reversed. MS02 means not specified reason, customer generated, which is used when the customer asks for a reversal for a reason that does not have a specific code. MS03 means not specified reason, agent generated, which is used when the bank or agent asks for a reversal for a reason that does not have a specific code. Other reason codes exist for different situations, such as a wrong amount, a wrong account, or a technical error. In the SDD context, a pacs.007 reversal is used when a collection was made in error, when it was duplicated, or when it needs to be undone for a technical reason. The reversal must be sent promptly, with the correct original reference and UETR, so the receiving bank can match it to the original payment. A reversal is not the same as a return or a refund. A return is bank initiated after settlement, a refund is debtor initiated under scheme rules, and a reversal is a technical undo of a settled transaction, usually with a specific reason code.

The SEPA recall flow is the process by which the originator bank asks the beneficiary bank to return funds that were sent in a SEPA Credit Transfer in error, and it uses ISO 20022 messages, specifically camt.056, camt.029, and pacs.004. The originator bank starts the recall by sending a camt.056, a payment cancellation request, to the beneficiary bank, with the UETR, the amount, the value date, and the reason for the recall, such as a duplicate payment, a wrong amount, or a wrong beneficiary. The beneficiary bank checks whether the funds are still available, whether the beneficiary agrees to the return, and whether local law allows the return, and it replies with a camt.029, a resolution of investigation, to say whether the recall was accepted or rejected. If the recall is accepted, the beneficiary bank returns the funds using a pacs.004, a payment return message, and the originator bank credits the originator. If the recall is rejected, for example because the beneficiary has already spent the funds or does not agree, the originator bank must tell the originator that the recall failed, and the originator must pursue the matter directly with the beneficiary. The SEPA recall flow is not a guaranteed refund. It is a request, and the beneficiary bank needs the beneficiary consent in many cases. The key to a successful recall is speed, accurate details, and a clear reason. A recall sent on the same day, with the correct UETR and amount, has a much better chance of success than a recall sent days later.

When a direct debit mandate is invalid or missing, the direct debit collection cannot be made, or if it has already been made, it can be refunded as an unauthorised transaction, because a mandate is the legal authorisation that allows a creditor to take money from a debtor account. A mandate must be signed by the debtor, must show the creditor name, the debtor name, the IBAN, and the mandate reference, and must be stored by the creditor. If the mandate is missing, the creditor has no authorisation to collect, and the debtor bank must reject the collection before settlement, using a pacs.002 with a reason code for a missing or invalid mandate. If the collection has already been debited, the debtor can claim a refund for an unauthorised transaction, up to 13 months after the debit, and the debtor bank must refund the debtor. If the mandate is invalid because it was cancelled, because the details do not match, because it was signed by the wrong person, or because it has expired, the same rules apply. The creditor must not send a collection without a valid mandate, and it must check the mandate before each collection. In SDD B2B, the debtor must also authorise the mandate with its bank before the first collection, and the bank must check that authorisation. A missing or invalid mandate is a serious failure, because it means the creditor took money without permission, and it can lead to refunds, complaints, and regulatory action. Creditors must keep mandates safely, and must be able to produce them when a debtor disputes a collection.

An R-transaction in SEPA is any transaction that is a reject, a return, a refund, a reversal, or a recall, in other words any transaction that reverses or undoes a normal payment, and the R stands for the fact that all these words start with R in English, except for recall which also starts with R. R-transactions are the exception flow in SEPA, and they are why 70 percent of SDD messages are for exceptions. Each R-transaction carries a reason code that explains why it happened, and the reason codes are standardised across SEPA so that every bank uses the same codes. Common reason codes include AM05 for duplication, MS02 for a not specified reason generated by the customer, MS03 for a not specified reason generated by the agent, AC01 for an incorrect account number, AC04 for a closed account, AC06 for a blocked account, MD01 for no mandate, MD02 for a missing mandatory information in the mandate, and AG01 for a transaction forbidden on this type of account. The reason code tells the creditor or the debtor why the collection failed, and it tells the operations team what to fix. For example, AC01 means the IBAN was wrong, MD01 means there was no mandate, and AM05 means the payment was duplicated. R-transactions use messages such as pacs.002 for a reject, pacs.004 for a return or refund, pacs.007 for a reversal, and camt.056 for a recall request. Understanding R-transactions and their reason codes is essential for SEPA operations, because most of the daily work is handling R-transactions, not happy path collections.

In SEPA, a reject, a return, a refund, a reversal, and a recall are five different R-transactions, and they differ in timing, in who starts them, and in which message is used. A reject happens before settlement, when the debtor bank refuses a collection because it cannot be processed, for example because the account does not exist or the mandate is invalid, and it uses a pacs.002 status report. A return happens after settlement, when the debtor bank sends the funds back because the collection cannot be applied, for example because the account was closed, and it uses a pacs.004 payment return. A refund happens after settlement, when the debtor claims a refund under scheme rules, for example a no-questions-asked refund up to 8 weeks, or an unauthorised refund up to 13 months, and it also uses a pacs.004. A reversal happens after settlement, when a payment is technically undone, for example because it was duplicated, and it uses a pacs.007 reversal with a reason code such as AM05, MS02, or MS03. A recall happens after settlement, when the originator bank asks the beneficiary bank to return funds sent in error in a credit transfer, and it uses a camt.056 cancellation request, a camt.029 resolution, and a pacs.004 return if accepted. The key is to ask when it happened, who started it, and which message was used. A reject is before settlement, a return and a refund are after settlement, a reversal is a technical undo, and a recall is a request to return funds. Mixing up these terms causes confusion in operations, in customer communication, and in reporting.

A payment engine is the central system in a bank that receives payment instructions, validates them, checks them, routes them, and sends them to the next bank or system, and it performs a series of checks on each payment before it is released. The payment engine first checks the format, to ensure that the message is well formed, that the fields are present, and that the values are valid. It then checks the account details, to ensure that the ordering account exists, that it has sufficient funds, and that the beneficiary account details are valid. It checks the sanctions lists, to ensure that no party to the payment is on a sanctions list, and it checks anti-money laundering rules, to ensure that the payment does not match a suspicious pattern. It checks the settlement instructions, the SSI, to find the correct correspondent bank and account for the currency and the destination. It checks the value date, the currency, and the charges instruction, such as SHA for shared charges. It checks for duplicates, by comparing the reference, the amount, and the UETR against recent payments. If any check fails, the payment is held in an exception queue for manual review, or it is rejected. If all checks pass, the payment is released straight through, which is called STP, straight through processing. In the worked example, the payment engine at BNP Paribas Paris would check the USD 367,574.90 payment, reference 103REF405775, before sending the MT103 to Banco Santander Madrid, and the payment engines at Wells Fargo and Bank of New York Mellon would check it again at each step.

STP is straight through processing, which means a payment is processed automatically from end to end, without manual intervention, because it passes all the validation, sanctions, and account checks in the payment engine. A payment that is STP goes from the ordering customer instruction, through the bank systems, to the correspondent banks, to the beneficiary bank, and to the beneficiary account, with no human touching it, which is fast, cheap, and reliable. 4EV is a related concept, and it stands for four eyes verification, or four eyes principle, which means that a payment must be checked by two people, or by two separate controls, before it is released, especially for high value, high risk, or manual payments. The four eyes principle is a control to prevent errors and fraud, because one person might make a mistake or might act dishonestly, but two people checking the same payment are less likely to both miss the same error. In practice, a bank will use STP for most low risk, standard payments, and will use 4EV for payments that are held in an exception queue, for large amounts, for manual repairs, or for payments that need a compliance approval. In the worked example, a USD 367,574.90 payment from BNP Paribas Paris to Banco Santander Madrid would normally be STP if all details are correct, but if it is held for a sanctions check, or if the amount is corrected manually, it would need 4EV approval before it is released. STP is about automation and speed, 4EV is about control and safety, and a good payment operation balances the two.

An SSI, Standing Settlement Instruction, is a standing instruction that a bank gives to its counterparties, telling them which correspondent bank and which account to use for settlement in a given currency, and it matters for routing because it tells the sending bank where to send the funds. Without an SSI, the sending bank would not know which correspondent to use, and the payment could be delayed, sent to the wrong account, or rejected. An SSI is set up in advance, and it is agreed between the two banks. It states, for example, that for USD payments, Bank A should settle through Wells Fargo, account number X, and for EUR payments, it should settle through a different correspondent. The SSI includes the correspondent BIC, the account number, and any other details needed to settle. In the worked example, BNP Paribas Paris has an SSI that tells it to settle USD payments through Wells Fargo, PNBPUS3N, and Banco Santander Madrid has an SSI that tells it to receive USD payments through Bank of New York Mellon, IRVTUS3N. When BNPP sends the USD 367,574.90 payment to Santander, it uses its SSI to route the cover through Wells Fargo, and Santander uses its SSI to receive the cover through BNY. If the SSI is wrong, outdated, or missing, the payment will be routed incorrectly, and it will go to an exception queue. SSIs must be kept up to date, checked regularly, and shared with counterparties promptly when they change, because a wrong SSI is a common cause of a failed or delayed payment.

The ISO 20022 equivalents of the classic SWIFT MT messages are part of the migration from MT to MX, and they map as follows. MT101, a request for transfer, which is a customer instruction to a bank to make a payment, maps to pain.001, a customer credit transfer initiation. MT103, a single customer credit transfer, maps to pacs.008, a financial institution to financial institution customer credit transfer. MT202, a general financial institution transfer, maps to pacs.009, a financial institution credit transfer. MT202 COV, a cover payment, also maps to pacs.009, but with the cover details and the underlying customer details carried in the pacs.009 structure, and with the UETR linking it to the pacs.008. MT940, a customer statement message, maps to camt.053, a bank to customer statement. MT941, a balance report, maps to camt.052, a bank to customer account report. MT942, an interim transaction report, also maps to camt.052, because camt.052 is used for both balance and interim transaction reports. In SEPA, the same ISO 20022 messages are used, with SEPA specific rules. A SEPA Credit Transfer uses pain.001 for initiation and pacs.008 for clearing, and a SEPA Direct Debit uses pain.008 for initiation and pacs.003 for clearing. In the worked example, an MT103 from BNP Paribas Paris to Banco Santander Madrid for USD 367,574.90 would be a pacs.008 in ISO 20022, and the MT202 COV cover from Bank of New York Mellon would be a pacs.009. Learning these mappings is essential, because the migration is now complete and cross border payments run on ISO 20022 end to end, while MT knowledge remains essential for reading historical messages and payment investigations.

A standby letter of credit is a bank undertaking to pay a beneficiary if the applicant fails to meet an obligation. It is a safety net, not the normal way of paying for goods or services. For example, a construction company in Dubai may ask its bank to issue a 500,000 dollar standby in favour of a project owner. If the company completes the work on time, the standby simply expires unused. If the company fails to complete the work, the project owner can present a demand and the required documents, and the bank must pay. The bank charges a fee for issuing the standby, usually a percentage of the amount each year, and it takes security or a credit limit from the applicant. The standby is independent of the underlying contract, which means the bank deals only with the documents presented, not with whether the work was truly defective. That independence is what makes the standby reliable for the beneficiary, because the bank cannot refuse to pay simply because the applicant disputes the claim. Standby letters of credit are used for performance guarantees, advance payment guarantees, bid bonds and financial guarantees, and they are common in construction, trade and large service contracts.

A commercial letter of credit is the primary payment method for a trade transaction, while a standby letter of credit is a backup that pays only on default. Under a commercial letter of credit, a seller in Mumbai ships goods worth 100,000 dollars to a buyer in London, presents the shipping documents to the bank, and is paid under the credit. The payment is expected and normal. Under a standby letter of credit, the beneficiary only draws when the applicant has failed to perform, for example when a supplier does not deliver goods that were already paid for. The documents also differ. A commercial credit usually requires a full set of shipping documents, such as a bill of lading, an invoice and an insurance certificate. A standby usually requires a simple written demand plus a statement that the applicant has defaulted, and sometimes a copy of an unpaid invoice. The commercial credit is therefore used in almost every shipment, while the standby sits unused in most cases and only springs into life when something goes wrong. Banks price them differently too, because the risk profile and the expected use are very different.

Issuance of a standby letter of credit starts when the applicant asks its bank to issue the standby in favour of a named beneficiary. The applicant is usually a company that must give a guarantee, for example a contractor bidding for a 2 million dollar project in Abu Dhabi. The bank first checks the applicant credit limit, takes any security it needs, and agrees the fee. The applicant then gives the bank the exact terms, including the beneficiary name, the amount, the currency, the expiry date and the documents required for a drawing. The issuing bank drafts the standby, often using a standard form, and sends it to the beneficiary through SWIFT, usually as an MT760 message. The beneficiary bank may add its confirmation if asked, which means it also undertakes to pay. Once issued, the standby is a firm obligation of the issuing bank, and the bank cannot cancel it without the beneficiary consent. The applicant must keep the credit limit available until the standby expires or is returned, because the bank must be ready to pay the full amount at any time.

Notification is the step where the beneficiary learns that a standby letter of credit has been issued in its favour and can rely on it. The issuing bank sends the standby through SWIFT to the beneficiary bank, which is often called the advising bank. The advising bank checks that the message appears genuine, that the signatures or authentication match, and that the terms are readable, then it forwards the standby to the beneficiary. The advising bank does not undertake to pay unless it also adds its confirmation. The beneficiary must read the standby carefully on receipt and check the amount, the currency, the expiry date, the documents required for drawing and the place of presentation. For example, if a 750,000 euro standby requires a demand to be presented in London by 15 December, the beneficiary must know that date and place, or a late presentation will be refused. If any term is wrong, the beneficiary should ask for an amendment before relying on the standby. A standby that is never notified is of no use, because the beneficiary cannot draw on a guarantee it does not know exists.

Drawing a standby letter of credit means the beneficiary presents a demand to the bank and asks for payment because the applicant has defaulted. The beneficiary must present the documents listed in the standby, usually a written demand for payment and a signed statement that the applicant has failed to perform. The presentation must be made before the expiry date and at the place stated in the standby. For example, a project owner in Qatar may present a demand for 300,000 dollars to the issuing bank in London, stating that the contractor failed to complete the work by the agreed date. The bank then has a limited time, usually up to five banking days, to examine the documents. The bank checks only that the documents appear to comply with the standby terms, not whether the contractor truly failed. If the documents comply, the bank must pay, even if the applicant objects. If the documents do not comply, the bank refuses and tells the beneficiary why, and the beneficiary may correct the presentation and try again before expiry if time allows.

UCP 600 is the set of rules published for documentary credits, and it can apply to standby letters of credit when the standby states that it is subject to UCP 600. Many standby credits do state this, especially those issued by banks that handle trade finance. Under UCP 600, the bank deals with documents, not with goods or services, and it must examine a presentation within five banking days. The rules cover how documents must be presented, what counts as a complying presentation, and how the bank must notify the beneficiary of a refusal. ISP98 is a separate set of rules written specifically for standby letters of credit, and many banks prefer it for standbys because it fits their structure better. ISP98 also follows the document based principle, but it has clearer rules for demands, for the expiry of a standby, and for the way a beneficiary can transfer its drawing rights. A standby will state which set of rules governs it, and the beneficiary and the applicant should read that clause carefully, because the choice affects how a drawing is examined and what happens if documents are not perfect.

The main parties to a standby letter of credit are the applicant, the issuing bank, the beneficiary and sometimes the advising or confirming bank. The applicant is the company that asks for the standby and whose obligation is guaranteed, for example a supplier in India that must guarantee delivery of equipment worth 400,000 dollars. The issuing bank is the bank that issues the standby and undertakes to pay the beneficiary if a complying demand is presented. The beneficiary is the party protected by the standby, such as the buyer who has paid an advance and wants a refund if the goods never arrive. The advising bank is the bank in the beneficiary country that notifies the beneficiary of the standby, without taking on a payment obligation. A confirming bank, if one is involved, adds its own undertaking to pay, which gives the beneficiary a local bank to claim from. Each party has a distinct role, and a business analyst mapping a standby flow should name each party, show the direction of each message and document, and state who pays whom and when.

A standby letter of credit expires on the date stated in the standby, and after that date the beneficiary can no longer draw. The expiry date is a critical term, and the beneficiary must present any demand before it passes. For example, a standby for 1 million dollars expiring on 30 June cannot be drawn on 1 July, even if the default happened in May. Some standbys contain an evergreen clause, which means the standby renews automatically each year unless the issuing bank gives notice that it will not renew. The bank must give that notice a set number of days before expiry, often 30 days, so the beneficiary has time to react. If the standby is no longer needed, the beneficiary can return it to the issuing bank or give a written release, which frees the applicant credit limit. A bank must keep a record of the expiry and release the limit only when it is certain that no drawing can still be made. Operations teams track expiry dates daily, because a missed expiry can leave a bank exposed to a claim it thought had ended.

MT101 is a SWIFT message that a customer uses to instruct its bank to make payments from its accounts, often many payments in one message. A corporate treasurer in London may send one MT101 to instruct the bank to pay 20 suppliers in different currencies, with the funds debited from several accounts. The message has two sequences. Sequence A describes the general instruction, including the ordering customer and the account to be debited for the first payment. Sequence B repeats for each individual payment, with the beneficiary, the amount, the currency and the value date. The bank receives the MT101, validates each instruction, checks the account balances, and then executes the payments through the appropriate clearing system or correspondent bank. MT101 is used for bulk payments, salary runs, supplier payments and treasury operations, and it is popular because one message can carry many instructions. The modern ISO 20022 equivalent is the pain.001 customer credit transfer initiation message, which serves the same purpose with richer data.

A single MT101 can debit several different accounts, which is useful when a group has accounts in several currencies or several subsidiaries. Sequence A carries the first account to be debited, and each Sequence B can carry its own debit account in field 50a. For example, a group may pay euro suppliers from its euro account in Frankfurt, dollar suppliers from its dollar account in New York, and pound suppliers from its pound account in London, all in one MT101. The bank must check that each account has enough funds or an agreed overdraft, and that the signatory has authority over each account. If one account is short of funds, the bank must decide whether to reject only that payment or the whole message, and the customer agreement should state the rule. The statement for each account will show its own debits, so reconciliation must match each payment to the right account. A business analyst designing an MT101 flow should therefore map every debit account, name the authority for each one, and test the case where one account fails while the others succeed.

A parent company can use MT101 to pay suppliers on behalf of its subsidiaries, which is common in a group with a central treasury. The parent holds the payment instruction, and each Sequence B in the MT101 carries the subsidiary account to be debited and the supplier to be paid. For example, a parent in Paris may pay a German supplier from its German subsidiary euro account, and a British supplier from its UK subsidiary pound account, all in one message. The bank checks that the parent has authority to instruct payments from each subsidiary account, which is usually set up through a mandate or a cash pooling agreement. The parent treasury gains control and visibility, because it sees all group payments in one place and can manage liquidity across the group. Each subsidiary still sees its own debits on its own statement, so the accounting stays correct. The arrangement needs clear rules for who approves each payment, what happens when a subsidiary account is short of funds, and how the intercompany accounting is recorded, because the parent is spending money that belongs to a separate legal entity.

Funds repatriation is the movement of money from a subsidiary back to its parent, often as a dividend or a return of surplus cash, and MT101 can instruct those movements. A subsidiary in Brazil may hold 2 million dollars in surplus cash that the parent in Amsterdam wants to bring home. The parent sends an MT101 instructing the bank to debit the subsidiary account and credit the parent account, with the correct value date and currency. The bank must check local rules before executing the payment, because some countries restrict how much money can leave, require tax clearance, or require central bank approval. The payment may also need a foreign exchange conversion, for example from Brazilian real to euros, and the MT101 can carry the exchange instruction or the bank can convert at its own rate. The parent treasury must record the movement as a dividend or an intercompany loan, depending on the structure, and keep the documents that prove the payment was lawful. A failed repatriation can leave cash trapped in a subsidiary, so the instruction must be tested with the local bank before it is sent.

Field 50a in Sequence A of an MT101 identifies the ordering customer, which is the party instructing the bank to make the payments. It usually holds the customer name and account number, or a BIC and account reference. Field 50a in Sequence B identifies the account to be debited for that individual payment, which may be different from the account in Sequence A. For example, Sequence A may name the parent company in London, while a Sequence B names the German subsidiary and its euro account in Frankfurt, because that payment must be debited there. The distinction matters because the bank uses Sequence A to check who is giving the instruction and whether that party has authority, and it uses Sequence B to check the funds, the account balance and the account mandate. If the two fields are confused, the bank may debit the wrong account or reject the instruction for lack of authority. A business analyst reading an MT101 should always check both fields, confirm which account each payment debits, and make sure the authority for each account is in place before the message is sent.

The pain.001 message is the ISO 20022 equivalent of the MT101, and it carries the same business purpose with richer and more structured data. A customer credit transfer initiation in pain.001 has a group header, a payment information block for each debit account, and a credit transfer transaction block for each payment. That structure maps closely to MT101, where Sequence A is the general instruction and each Sequence B is one payment. The pain.001 can hold structured party names and addresses, a clear purpose code, and detailed remittance information, which the MT101 can only hold in limited free text fields. For example, a pain.001 paying 40 suppliers can carry the full invoice number and invoice date for each one, while an MT101 may have to shorten that information. Banks migrating from MT101 to pain.001 must map each MT101 field to its pain.001 equivalent, test the mapping with real data, and agree with customers how long names and long remittance details will be handled. The business purpose does not change, but the data quality and the straight through processing rate should improve.

MT101 is used for bulk salary payments, supplier payment runs, treasury transfers and regular standing instructions that a corporate customer sends to its bank. A company with 500 employees may send one MT101 each month to pay salaries from its main operating account, with one Sequence B per employee, each carrying the employee name, account and salary amount. The bank executes the payments, credits each employee account, and reports the results back to the company. MT101 is also used for supplier runs, where a company pays 100 suppliers on a Friday, and for intercompany transfers, where a group moves money between its own accounts. The message is suited to payments where the customer, not the bank, decides the timing, the amount and the beneficiary. It is not used for a single urgent payment, where a direct instruction or an online banking payment is simpler, and it is not used for collections, where the bank is asked to collect money rather than pay it. The key test is whether the customer wants to send many payment instructions in one structured message.

When an MT101 payment fails, the bank must tell the customer what went wrong and what happens next, and the customer must know how to fix it. Common failures include an account with insufficient funds, a beneficiary account number that does not exist, a currency that the receiving bank cannot accept, or a sanctions screening hit on a name. For example, if a 25,000 euro payment to a supplier in Italy fails because the beneficiary IBAN is wrong, the bank will return the payment or hold it in a repair queue, depending on the agreement. The bank usually sends a status report, often as an MT199 or a pain.002 payment status report, stating which Sequence B failed and why. The customer can then correct the IBAN and resend that one payment, without resending the whole MT101. A good MT101 agreement states the cut off time, the repair process, the charges for a failed payment, and who bears the cost of a correction. Operations teams should test the failure cases before go live, because a bulk payment run that fails silently can leave dozens of suppliers unpaid.

A documentary collection is a payment method where a seller ships goods and asks banks to collect the payment from the buyer in exchange for the shipping documents. The seller in Rotterdam ships machinery worth 180,000 euros to a buyer in Mumbai, then gives the bill of lading, the invoice and the insurance certificate to its bank. That bank, the remitting bank, sends the documents to a bank in India, the collecting bank, with instructions to release them only when the buyer pays or accepts a bill of exchange. The buyer cannot take the goods from the port without the bill of lading, so the seller has some protection, but the banks do not guarantee payment. If the buyer refuses to pay, the collecting bank holds the documents and asks the remitting bank what to do. Documentary collections are cheaper than letters of credit and are used when the buyer and seller trust each other enough to trade without a bank guarantee, but not enough to ship on open account terms.

The remitting bank is the bank that acts for the seller, also called the principal, and starts the documentary collection. The seller gives the documents and a collection instruction to the remitting bank, which checks that the documents match the instruction and then sends them to the collecting bank. The collecting bank is the bank in the buyer country that receives the documents and presents them to the buyer, who is called the drawee. For example, a seller in Hamburg gives documents to its bank in Germany, the remitting bank, which sends them to a bank in Shanghai, the collecting bank. The Shanghai bank tells the buyer that the documents have arrived and asks for payment or acceptance, depending on the terms. The collecting bank does not guarantee that the buyer will pay, and it releases the documents only when the buyer meets the conditions in the instruction. If the buyer refuses, the collecting bank informs the remitting bank and waits for new instructions. The two banks therefore play opposite roles in the same flow.

Before funds are collected in a documentary collection, the collecting bank must present the documents to the buyer and wait for the buyer to meet the conditions. In a documents against payment collection, the buyer must pay the full amount before the bank releases the bill of lading. In a documents against acceptance collection, the buyer must accept a bill of exchange promising to pay at a future date, for example 60 days after sight, and the bank then releases the documents. The collecting bank holds the documents safely until that moment, and it must not release them early, even if the buyer asks nicely. The bank also checks that the payment, when it arrives, matches the amount in the instruction, and it deducts its charges if the instruction allows. The funds are then remitted to the remitting bank, which credits the seller. If the buyer does not pay or accept within the time allowed, the collecting bank reports the non-payment and holds the documents until the remitting bank gives new instructions, which may be to return the goods or to try a new buyer.

SWIFT Category 4 covers messages used for collections and cash letters, which are the messages banks send when they handle documentary collections and cheque collections. The best known message is the MT400, which is the advice of payment in a collection. Other messages in the category cover the collection instruction itself, the advice of non-payment, and the advice of acceptance. For example, when a collecting bank in Mumbai receives payment of 180,000 euros from a buyer, it sends an MT400 to the remitting bank in Rotterdam to confirm that the funds have been collected and remitted. If the buyer refuses to pay, the collecting bank sends a message advising non-payment, so the remitting bank can tell the seller. Category 4 messages are therefore the working messages of the collections business, and an operations analyst who handles documentary collections will see them every day. They are distinct from Category 1 messages, which cover customer payments, and Category 7 messages, which cover documentary credits and guarantees.

MT400 is the SWIFT message that advises payment under a documentary collection. When the collecting bank has received the money from the buyer, it sends an MT400 to the remitting bank to confirm the collection and the remittance of funds. For example, a collecting bank in Mumbai collects 180,000 euros from a buyer and sends an MT400 to the remitting bank in Rotterdam, stating the amount collected, the currency, the value date and the charges deducted. The MT400 may also state the exchange rate if a conversion took place, and the account to which the funds were sent. The remitting bank uses the MT400 to credit the seller account and to close the collection in its own system. The message is important because the seller has no other proof that the buyer paid, and the remitting bank needs the details to reconcile the collection. If the MT400 is delayed, the seller may chase the bank for the money, so collecting banks send it promptly once the funds are good and available.

Documents against payment, often shortened to D/P, means the buyer must pay before the collecting bank releases the shipping documents. Documents against acceptance, shortened to D/A, means the buyer must accept a bill of exchange, promising to pay at a future date, before the documents are released. The difference matters for risk. Under D/P, the seller gets the money before the buyer gets the goods, so the seller is protected. Under D/A, the buyer gets the goods now and pays later, for example 90 days after sight, so the buyer has the goods and the seller carries the credit risk. A seller in Milan shipping textiles worth 60,000 dollars to a buyer in Cairo may accept D/A only if it trusts the buyer and has credit insurance, but it will insist on D/P for a new buyer. The collection instruction must state clearly which term applies, because the collecting bank will follow it exactly. A mistake in the instruction can release the documents too early and leave the seller without goods and without payment.

The URC 522 rules govern documentary collections, and they set out how banks should handle them. The rules state that banks deal with documents and instructions, not with the goods themselves, and that banks are not responsible for the quality, quantity or value of the goods shipped. They also state that the collecting bank must present the documents promptly, must not release them until the buyer meets the conditions, and must advise the remitting bank if the buyer refuses to pay or accept. For example, if a buyer in Jakarta refuses a collection for 95,000 dollars, the collecting bank must send an advice of non-payment and hold the documents until it receives new instructions. The rules also cover how banks handle protest, how charges are applied, and what happens when documents are lost. A business analyst working on collections should know that URC 522 is the rulebook for collections in the same way that UCP 600 is the rulebook for letters of credit, and that a collection instruction should state that it is subject to URC 522.

SWIFT Category 4 also covers cash letters, which are used when banks send cheques for collection across borders. A cash letter is a list of cheques sent by one bank to another for collection, with the total amount and the details of each cheque. For example, a bank in London may send a cash letter with 50 cheques worth 200,000 dollars in total to a bank in New York, asking it to collect the funds and remit them. The receiving bank presents each cheque to the paying bank, collects the money, and reports the result, including any cheques that were returned unpaid. Category 4 messages carry the advice of payment, the advice of non-payment and the details of the cheques collected. Cash letters are less common today than they once were, because cheques have declined in many markets, but they are still used in some corridors, especially in the United States. An operations analyst in a collections team may therefore still see cash letter work alongside documentary collections.

MT940 is a SWIFT message that gives a customer a statement of its account, usually at the end of each business day. The message starts with field 20, the transaction reference, and field 25, the account number, so the customer knows which account the statement covers. Field 60a is the opening balance, field 62a is the closing booked balance, field 64 is the closing available balance, and field 65 is the forward available balance. Each transaction is listed in field 86 or in the statement lines, with the amount, the value date and a description. For example, a corporate treasurer in Frankfurt receives an MT940 each morning for its euro account, showing the opening balance of 1.2 million euros, the payments made during the day, and the closing balance. The treasurer uses the MT940 to reconcile the account, to check that expected receipts arrived, and to plan the next day cash position. MT940 is a bank to customer statement, so it is sent by the bank to the account holder, not between banks.

Field 60a in an MT940 is the opening balance, which is the balance of the account at the start of the statement period. It is calculated from the closing balance of the previous statement, and it should match exactly, or the reconciliation will fail from the first line. Field 60a carries a debit or credit mark, the date, the currency and the amount. For example, if an account closed the previous day with a credit balance of 450,000 euros, field 60a on the next MT940 will show a credit balance of 450,000 euros on the new statement date. The opening balance is the anchor for the whole statement. Every transaction in the statement is added to or subtracted from it to reach the closing balance, so an error in field 60a makes every later figure wrong. A reconciliation analyst always checks field 60a first, compares it with the previous closing balance, and investigates any difference before looking at the individual transactions.

Field 62a in an MT940 is the closing booked balance, which is the balance after all transactions booked during the statement period have been applied. It is calculated by taking the opening balance in field 60a, adding all booked credits, and subtracting all booked debits. For example, if an account opens with 450,000 euros, receives credits of 120,000 euros and pays debits of 80,000 euros, field 62a will show a credit balance of 490,000 euros. Booked means the transactions have been posted to the account, even if their value date is in the future. The closing booked balance is the figure most customers use to check their account, because it reflects everything the bank has recorded. A reconciliation analyst checks field 62a against the ledger, and if the two differ, the analyst looks for a missing transaction, a duplicated entry or a transaction booked on the wrong date. The calculation is simple, but the discipline of checking it every day is what keeps an account clean.

Field 64 in an MT940 is the closing available balance, which is the amount the customer can actually use at the end of the statement period. It starts from the closing booked balance in field 62a and adjusts for items that are booked but not yet available, such as a cheque that has been credited but not yet cleared, or a payment with a future value date. For example, if the closing booked balance is 490,000 euros but 30,000 euros of that is a cheque that clears tomorrow, field 64 will show 460,000 euros available. Field 65 is the forward available balance, which shows the balance that will be available on a future date stated in the field. If a payment of 50,000 euros is due to arrive on Friday, field 65 may show the balance expected on that Friday. The distinction matters for a treasurer, who must know not only what the ledger says, but what can be spent today and what will be available later in the week.

MT910 is a SWIFT message that confirms a credit to an account. When a bank credits a customer account, it can send an MT910 to tell the customer that the money has arrived. For example, a supplier in Singapore receives a payment of 75,000 dollars from a buyer in Germany, and the supplier bank sends an MT910 stating the amount, the currency, the value date and the sender reference. The customer can then match the credit to an invoice and update its own records. MT910 is a single credit confirmation, not a full statement, so it is sent when one credit needs to be confirmed quickly, rather than waiting for the end of day MT940. It is often used for large or urgent credits, where the customer needs to know immediately that the funds are available. The message carries field 20 for the transaction reference, field 21 for the related reference, field 25 for the account number, and field 32A for the value date, currency and amount, so the customer has all the details needed to reconcile the credit.

MT950 is a SWIFT statement message, similar to MT940, but it is used for a statement that covers a longer period or a different format. Both messages give the customer the opening balance, the transactions and the closing balance for an account. The MT940 is usually the end of day statement, sent daily, while the MT950 is often used for a periodic statement, such as a weekly or monthly statement, or for a statement requested by the customer. For example, a corporate treasurer may receive an MT940 every morning for daily cash management, and an MT950 at month end for the accounting close. The fields are similar, including field 60a for the opening balance, field 62a for the closing booked balance, and field 86 for transaction details. The main difference is the frequency and the purpose, not the content. A business analyst should check which statement the customer receives, how often it arrives, and whether the reconciliation system can handle both formats, because a system built only for MT940 may fail on an MT950.

A treasurer reconciles an MT940 to the ledger by comparing the opening balance, each transaction and the closing balance with the company own records. The first step is to check field 60a against the previous closing balance, so the reconciliation starts from a known point. The treasurer then matches each transaction in the statement to a payment or receipt in the ledger, using the amount, the value date and the reference. For example, a 25,000 euro supplier payment in the ledger should appear as a 25,000 euro debit in the MT940 with the same value date. Any transaction in the statement that is not in the ledger, or in the ledger but not in the statement, is an exception that must be investigated. Common causes include a bank charge the company did not expect, a payment booked on the wrong date, or a receipt from a customer with a missing reference. The treasurer records each exception, follows it up with the bank or the internal team, and only signs off the reconciliation when the closing balance in field 62a matches the ledger exactly.

MT940, MT950 and MT910 serve different reporting needs, and a customer may receive all three. MT940 is the daily end of day statement, showing the opening balance, all transactions and the closing balance for one account. MT950 is a periodic statement, often weekly or monthly, with the same structure but a longer period. MT910 is a single credit confirmation, sent when one credit needs to be confirmed quickly, without waiting for the statement. For example, a treasurer may receive an MT910 at 10 in the morning when a 500,000 dollar receipt arrives, an MT940 the next morning showing that receipt among the day transactions, and an MT950 at month end for the accounting close. The MT910 is the fastest, the MT940 is the daily control, and the MT950 is the periodic record. A reconciliation system must handle all three, because a credit confirmed by MT910 should also appear in the MT940 and the MT950, and a missing entry in any one of them is a sign of a problem.

Field 52a in an MT103 identifies the ordering institution, which is the bank that the ordering customer instructed to make the payment. It is optional, and it is used when the ordering institution is different from the sender of the message. For example, a customer in Mumbai may instruct its bank in India to send a payment, but the payment is actually sent by a branch in Singapore, so field 52a names the Indian bank as the ordering institution. The field can hold a BIC, a name and address, or a party identifier. The receiving bank uses field 52a to know who really ordered the payment, which matters for sanctions screening and for returning the payment if it fails. If the field is missing, the receiving bank assumes the sender is also the ordering institution, which is true in most simple payments. A business analyst should check field 52a whenever a payment involves a branch, a subsidiary bank or a payment service provider, because the ordering institution may not be the bank that sent the SWIFT message.

Field 57a in an MT103 identifies the account with institution, which is the bank where the beneficiary holds its account. It is optional, and it is used when the beneficiary bank is different from the receiver of the message. For example, an MT103 for a 40,000 dollar payment to a supplier in Kenya may be sent to a large correspondent bank in London, but field 57a names the small Kenyan bank where the supplier account is held. The correspondent bank then forwards the payment to that bank, which credits the supplier. Without field 57a, the receiving bank might not know where to send the payment next, and the payment could be delayed or returned. Field 57a can hold a BIC, which is the cleanest option, or a name and address. A business analyst should always check field 57a on a payment to a small or remote bank, because the routing depends on it, and a missing or wrong field 57a is a common cause of a payment sitting in a repair queue.

Field 53B in an MT103 identifies the sender correspondent account, which is the account the sender holds with the receiver, or the account through which the payment will be settled. It is optional, and it is used in bank to bank settlement, especially in cover payments and in payments where the sender and receiver have a direct account relationship. For example, a bank in Frankfurt sending a 2 million euro payment to a bank in Tokyo may state in field 53B that the payment should be settled through its euro account held with the Tokyo bank. The receiving bank then debits that account, rather than asking for funds through another route. Field 53B carries the account number and sometimes the currency, and it must match the account the two banks have agreed for settlement. If the field is wrong, the receiving bank may not find the account, and the payment will be held for repair. A business analyst should treat field 53B as a settlement instruction, not as a customer detail, and check it against the nostro account records.

Field 70 in an MT103 carries remittance information, which tells the beneficiary what the payment is for. It can hold an invoice number, a contract reference, a description of the goods, or a short message from the payer. For example, a buyer in London paying 30,000 pounds to a supplier in Paris may put invoice number INV-2024-118 in field 70, so the supplier can match the payment to the invoice without a phone call. Field 70 is optional, but it is one of the most useful fields for the beneficiary, because it makes reconciliation possible. The field is limited in length in the MT format, so long remittance details may be shortened, and the ISO 20022 pacs.008 carries far richer remittance information. A business analyst should encourage customers to use field 70 well, with a clear invoice number and date, rather than a vague note such as payment for goods, which helps no one. A payment with good remittance information is posted faster and with fewer queries than one without it.

Field 71G in an MT103 states the receiver charges, which are the charges that the beneficiary bank will deduct from the payment amount. It is optional, and it is used when the sender wants the beneficiary to know exactly how much will be deducted, or when the charges must be stated for the payment to be processed correctly. For example, if a payment of 10,000 dollars is sent with receiver charges of 25 dollars in field 71G, the beneficiary will receive 9,975 dollars. Field 71G is different from field 71A, which states who bears the charges using OUR, SHA or BEN, and from field 71F, which states the sender charges. A payment with OUR in field 71A means the sender pays all charges, so the beneficiary should receive the full amount, while SHA means the charges are shared. A business analyst should read field 71G together with field 71A, because the two fields together explain the final amount the beneficiary receives, and a mismatch between them is a common source of customer complaints.

Field 71A in an MT103 states who bears the charges for the payment, using one of three codes. OUR means the ordering customer pays all charges, so the beneficiary receives the full amount. SHA means the charges are shared, so the sender pays the sending bank charges and the beneficiary pays the receiving bank charges. BEN means the beneficiary pays all charges, so the charges are deducted from the payment amount. For example, a 50,000 euro payment sent with OUR should arrive as 50,000 euros, while the same payment sent with BEN may arrive as 49,950 euros after charges. The choice of code is a commercial decision, often agreed in the contract between buyer and seller. A supplier may insist on OUR, so it receives the full invoice amount, while a buyer may prefer SHA as the standard. A business analyst should check field 71A on every payment, because the code changes the amount the beneficiary receives and can cause a dispute if the contract says one thing and the payment says another.

A complete MT103 with all optional fields tells a full story about a payment, and reading it is a core skill for a payments analyst. Take a pre-migration payment of 75,000 dollars from a buyer in New York to a supplier in Tokyo. Field 52a names the ordering institution in New York, field 53B names the sender correspondent account for settlement, field 57a names the Japanese bank where the supplier holds its account, field 70 carries the invoice number INV-8841, and field 71G states receiver charges of 30 dollars. The mandatory fields carry the sender, the receiver, the amount, the currency, the value date, the ordering customer and the beneficiary. Together, the mandatory and optional fields let the analyst trace the payment from the ordering customer to the beneficiary, know how it will be settled, know what it is for, and know what the beneficiary will receive. An analyst who can read a full MT103 can spot a missing intermediary, a wrong charge code or a remittance reference that does not match the invoice, before the payment is sent.

Optional fields in an MT103 are often left out, but leaving them out can cause delays, extra charges or a payment that cannot be reconciled. If field 57a is missing, the receiving bank may not know which bank holds the beneficiary account, and the payment may sit in a repair queue. If field 70 is missing, the beneficiary may not know which invoice the payment covers, and may chase the payer for information. If field 71G is missing, the beneficiary may not know how much will be deducted, and may complain when the amount received is less than the invoice. For example, a 20,000 pound payment to a supplier in Nigeria without field 57a may take three extra days while the correspondent bank asks for the beneficiary bank details. The sender should therefore use the optional fields whenever the information is known, especially for payments to small banks, payments with charges, and payments that must be matched to an invoice. A business analyst should treat the optional fields as part of the payment, not as extras, and should test that the bank system captures and sends them correctly.

SWIFT, the Society for Worldwide Interbank Financial Telecommunication, is a member owned cooperative that provides secure messaging between banks and financial institutions around the world. SWIFT does not move money itself. It moves the instructions that tell banks to move money. A bank in London sending a payment to a bank in Tokyo sends a SWIFT message, and the actual settlement happens through correspondent accounts or a clearing system. SWIFT provides the network, called SWIFTNet, the message standards, and the security that lets banks trust the messages they receive. More than 11,000 institutions in over 200 countries use SWIFT, and it carries millions of messages every day, covering payments, trade finance, securities and treasury. A business analyst should remember the distinction between the message and the money, because a SWIFT message that is sent does not mean the money has moved, and a payment can be instructed by SWIFT but settled by another route. That distinction explains many of the delays and reconciliation issues in cross border payments.

SWIFTNet is the secure private network that SWIFT members use to exchange messages. It is not the public internet. It is a closed network with strong authentication, encryption and access controls, so only authorised institutions can send and receive messages. A bank connects to SWIFTNet through an interface, often called a SWIFT gateway, which sits inside the bank and connects to its payment systems. When a payment officer releases a payment, the gateway formats the message, checks it against the SWIFT standards, and sends it over SWIFTNet to the receiving bank. The receiving bank gateway checks the message, validates the authentication, and passes it to its own payment system. SWIFTNet also carries other services, such as file transfer and interactive services, but messaging is the core use. The security of SWIFTNet is why banks trust a message that arrives through it, and why a breach of a bank gateway, rather than of SWIFTNet itself, has been the cause of the most serious frauds in recent years.

SWIFT messages are grouped into categories, each covering a business area, and into message types, each covering a specific function. Category 1 covers customer payments and cheques, and includes the MT103 customer credit transfer. Category 2 covers financial institution transfers, including the MT202. Category 3 covers treasury markets, Category 4 covers collections and cash letters, Category 5 covers securities, Category 7 covers documentary credits and guarantees, and Category 9 covers cash management and customer status. The message type is the three digit number, such as 103, 202 or 940, and the first digit is the category. So an MT103 is a Category 1 message, and an MT940 is a Category 9 message. The category system helps an analyst know what a message is for before reading it in detail. If a message starts with MT7, it is about a letter of credit, and if it starts with MT9, it is about cash management or a statement. That quick classification is a useful first step when reading a raw message or a payment file.

A BIC, or Business Identifier Code, is the standard code that identifies a bank or financial institution in SWIFT messages. It is defined by ISO 9362, and it has eight or eleven characters. The first four characters are the bank code, the next two are the country code, the next two are the location code, and the final three, when present, are the branch code. For example, a BIC for a bank in London might start with four letters for the bank, then GB for the United Kingdom, then LD for London, then a branch code such as 123. An eight character BIC identifies the head office or the main branch, while an eleven character BIC identifies a specific branch. The BIC is used in field 52a, field 57a and many other fields to name a bank without ambiguity, because bank names can be similar but a BIC is unique. A business analyst should be able to split a BIC into its parts and check that the country code matches the country where the bank is located, because a wrong BIC will send a payment to the wrong bank.

Every SWIFT MT message is built from up to five blocks, each wrapped in curly brackets and numbered 1 to 5. Block 1 is the basic header, which identifies the sender, the session and the sequence number. Block 2 is the application header, which states the message type, such as 103 or 202, and whether the message is incoming or outgoing. Block 3 is the user header, which is optional and carries extra routing data, such as a user reference. Block 4 is the text block, which holds the business data, organised as tagged fields such as field 20, field 32A and field 59. Block 5 is the trailers block, which holds the checksum and other system trailers, and it is added by SWIFT itself. The order is always 1, 2, 3, 4, 5. A reader who can recognise each block can split a raw message into its envelope, its routing data, its business content and its integrity check. That skill is the first step in reading any MT message, and it is used by operations analysts, developers and testers every day.

The mandatory fields of an MT103 are the fields that must be present for the message to be accepted by SWIFT and by the receiving bank. Field 20 is the sender transaction reference, field 32A is the value date, currency and amount, field 50a is the ordering customer, field 59 is the beneficiary customer, and field 71A is the details of charges. The message also needs the basic header and the application header, which identify the sender, the receiver and the message type. For example, a pre-migration payment of 60,000 euros from a buyer in Paris to a supplier in Berlin must carry the reference in field 20, the value date and amount in field 32A, the buyer details in field 50a, the supplier details in field 59, and the charge code in field 71A. If any mandatory field is missing or badly formatted, SWIFT will reject the message, or the receiving bank will return it for repair. Optional fields, such as 52a, 57a, 53B, 70 and 71G, add useful information, but the mandatory fields are the minimum needed to move the money.

Field 32A in an MT103 carries the value date, the currency code and the amount of the payment, and it is one of the most important fields in the message. The value date is the date on which the funds should be available to the beneficiary, and it is written as a six digit date. The currency is a three letter code, such as EUR, USD or GBP, and the amount is written with a comma as the decimal separator. For example, field 32A for a payment of 125,000 dollars value 12 May 2025 would show the date, USD and 125000,00. The receiving bank uses field 32A to know how much to credit, in which currency, and on which date. If the value date is wrong, the beneficiary may receive the money late, and if the amount is wrong, the payment may be short or overpaid. A business analyst should always check field 32A first when reading an MT103, because the amount and the value date are the heart of the payment, and every other field exists to support them.

Field 59 in an MT103 identifies the beneficiary customer, which is the person or company that should receive the payment. It carries the beneficiary account number and the beneficiary name and address. The account number is usually an IBAN in Europe, or a local account number in other markets. For example, a payment to a supplier in Milan may carry the supplier IBAN, the company name, and the street address in field 59. The receiving bank uses field 59 to credit the right account, and it must match the account number to the name, or the payment may be held for a check. If the account number is wrong, the payment may be credited to the wrong person, or returned. A business analyst should treat field 59 as a critical field, because the beneficiary details are the destination of the money, and a mistake here is hard to correct once the payment has been credited. The ordering customer should always confirm the beneficiary details with the supplier before sending the payment.

One leg out is a model where one part of a payment travels on ISO 20022 and the other part travels on an older format, such as an MT message. It happens when a payment starts or ends in a market that has not yet moved to ISO 20022, while the middle of the journey runs on the new standard. For example, a 120,000 euro payment from a German exporter to a buyer in a market still using MT messages may travel as a pacs.008 through Europe and then convert to an MT103 for the final leg. The risk is at the boundary, where rich ISO 20022 data, such as structured addresses and purpose codes, may not fit into the older format. If the converting bank truncates a name or drops a purpose code, the receiving bank may fail its sanctions screening or reject the payment. Banks must therefore map each field, decide what is preserved and what is lost, and test the full journey including the conversion point. Until the whole world moves to ISO 20022, one leg out is a normal operating model, not a temporary exception.

CBPR+ is the programme that moved cross border payments onto ISO 20022, and after the migration the work shifts from getting messages through to using the data inside them. The next priorities are straight through processing, better sanctions screening and richer customer services. With structured names, addresses and purpose codes, banks can automate more decisions, reduce repair queues and release genuine payments faster. A corporate treasurer sending 80 salary payments to five countries expects each one to settle without a phone call, and rich data makes that possible when banks align their validation rules. Sanctions screening also improves, because structured data is easier to match against a watchlist than free text, which means fewer false positives. Banks can also offer payment tracking and clearer fee breakdowns, because the message now carries the data needed to explain where a payment is. The banks that invest in data quality, correspondent alignment and customer facing services will turn a costly migration into lower cost and a better service.

Open banking lets a regulated third party start a payment directly from a customer bank account, with the customer consent, instead of using a card network. A shopper buying a 180 pound jacket online can choose pay by bank, approve the payment in their banking app, and send the money straight from their current account to the merchant. No card number is shared, no card fee is charged, and the merchant receives the funds faster than a card settlement cycle. Consent is the foundation. The customer must approve the amount and the payee, and the third party cannot take money without that approval. The bank checks the consent before it releases funds, and the customer can withdraw consent for future access. Open banking also gives the merchant clean, structured payment details, so reconciliation is easier. The risks are different from card payments, because an instant payment is hard to recall, so banks need strong authentication, transaction monitoring and clear liability rules. For banks, open banking is both a threat to card income and a chance to offer new services.

Cryptocurrencies are digital assets that move on a distributed ledger, without a central bank or a traditional clearing system in the middle. Bitcoin is the best known example, but its price can move sharply in a single day, which makes it a poor choice for paying a supplier who needs a known amount. A stablecoin solves that problem by linking its value to a stable asset, usually the United States dollar, so one unit should always equal one dollar. A business can send 50,000 dollars in stablecoins and the receiver knows the value on arrival, at least when the stablecoin holds its peg. Settlement can happen in minutes, at any hour, including weekends when traditional systems are closed. Banks are also testing tokenised deposits, which are bank deposits represented as digital tokens, and central bank digital currencies, which are digital forms of central bank money. Regulation remains the main brake, because a stablecoin issuer must hold reserves that match the coins in circulation and follow anti money laundering rules. The useful innovations are instant settlement and programmable payments, not price speculation.

Open banking and crypto together describe a payment that starts in a regulated bank account and settles on a digital ledger. A customer could approve a payment in their banking app, the open banking interface could pass the instruction to a regulated payment firm, and that firm could convert the funds and settle them in a stablecoin to a supplier overseas. The customer sees one approval, while behind the scenes a bank ledger and a distributed ledger must agree on the amount, the payee and the timing. The combination is attractive because open banking brings strong authentication, clear consent and a regulated source of funds, while crypto brings instant settlement, weekend availability and lower cost for the cross border leg. A small business in London paying a 12,000 euro invoice to a supplier in Kenya could approve the payment on a Friday evening and see it settle the same night. The risks are real too, including more parties in the flow, custody of the stablecoins, and compliance that must span both worlds. A design must name who holds the funds at each step and how a failure is handled.

For banks, business analysts and architects, the changes in this chapter mean new skills and new design habits. Banks must move from closed, batch based processing to open, real time services that customers can see and control, with product owners who understand the whole payment journey. A business analyst who only knows MT message formats will be less useful than one who can also read a pacs.008, explain an application programming interface contract, and describe a stablecoin settlement flow. The analyst does not need to code, but must be able to ask whether an interface returns the right error, whether a consent record is stored correctly, and whether a conversion failure has a clear repair path. Architects must design modular systems that handle MT and ISO 20022 side by side, connect to open banking interfaces, and leave room for a digital asset rail. Data quality becomes a career skill, because open banking and ISO 20022 only work when party data and account data are clean and structured. The practical step is to learn by tracing real payments end to end.

The four strategies to understand cross border payments are the open loop model, the correspondent banking model, the role of the SWIFT network, and access to the foreign exchange market. The open loop model describes payments that move through open networks where many banks can take part, rather than a closed loop run by one provider. Correspondent banking describes how banks hold accounts with each other, called nostro and vostro accounts, so they can settle payments in currencies where they have no branch. The SWIFT network provides the secure messaging that tells banks to move money, without moving the money itself. Foreign exchange market access describes how a payment in one currency is converted to another, and who provides the rate and bears the risk. A payment of 100,000 dollars from a buyer in India to a seller in Germany touches all four, because it needs a network, a correspondent account, a SWIFT message and a conversion from rupees to euros or dollars. A learner who can explain each strategy, and how they fit together, can read almost any cross border payment flow.

An open loop model is a payment system where many different banks and providers can take part, and a payment can move between any two participants through shared rules and shared infrastructure. The card networks are a familiar example, because a card issued by one bank can be used at a merchant whose bank is different, and the network routes the payment between them. In cross border payments, an open loop model means a payment is not confined to one bank group or one provider, but can travel through correspondent banks, clearing systems and messaging networks that many banks share. For example, a 20,000 dollar payment from a small bank in Vietnam to a supplier in France can move through the open network of correspondent banks and SWIFT messaging, even though the two banks have no direct relationship. The advantage is reach, because the network connects thousands of banks. The disadvantage is complexity, because each hop adds a fee, a delay and a chance of an error. A closed loop model, by contrast, keeps the payment inside one provider, which is faster but only works when both parties use the same provider.

Correspondent banking is the arrangement where one bank holds an account with another bank in a foreign country, so it can make and receive payments in that currency. The account is called a nostro account by the bank that owns it, and a vostro account by the bank that holds it. For example, a bank in India that has no branch in the United States holds a dollar nostro account with a bank in New York. When its customer in Mumbai pays 250,000 dollars to a supplier in Chicago, the Indian bank instructs its New York correspondent to debit its nostro account and credit the supplier bank. The SWIFT message carries the instruction, and the nostro account carries the settlement. Correspondent banking is the plumbing of cross border payments, and without it most banks could only pay in their home currency. The model is under pressure from de-risking, where large banks close correspondent accounts for smaller banks, and from new models such as instant payment links between countries, but it still carries the majority of cross border payments today.

The SWIFT network plays a central role in cross border payments by carrying the secure messages that instruct banks to move money. When a bank in London sends a payment to a bank in Tokyo, it sends an MT103 over SWIFTNet, and the receiving bank acts on that instruction. SWIFT does not hold the money, does not settle the payment, and does not convert the currency. The settlement happens through correspondent accounts, and the conversion happens in the foreign exchange market or at the sending bank. SWIFT provides the trust, because a message that arrives over SWIFTNet is authenticated, standardised and traceable, so the receiving bank knows who sent it and what it means. A payment can also be instructed by other means, such as a local clearing system or an application programming interface, but SWIFT remains the common language for cross border payments between banks that have no direct link. A learner should always separate the message from the money, because a SWIFT message that is sent is not proof that the funds have settled.

Foreign exchange market access decides how a cross border payment is converted from one currency to another, and who provides the rate. A customer paying in euros for goods priced in dollars needs a conversion, and the bank can provide the rate itself, buy the currency from another bank, or use a foreign exchange provider. For example, a buyer in Paris paying 80,000 dollars to a supplier in New York may ask its bank in France to convert euros to dollars at an agreed rate, with the rate and the margin stated before the payment is sent. Large banks trade directly in the foreign exchange market, while smaller banks buy currency from a larger correspondent. The rate, the timing of the conversion, and the margin all affect the final cost, and a customer who does not check them may pay far more than the headline fee. Some payments are converted at the sending bank, some at the receiving bank, and some in the middle of the correspondent chain. A business analyst should always ask where the conversion happens, what rate is used, and who bears the risk if the rate moves between instruction and settlement.

SEPA, SWIFT and UK Faster Payments serve different purposes, and a business should choose between them by corridor, currency, speed and cost. SEPA is the Single Euro Payments Area, which covers euro payments between banks in Europe, usually settling within one business day, or instantly under SEPA Instant. SWIFT is the global messaging network used for cross border payments in any currency, where a payment may take one to three days and pass through correspondent banks. UK Faster Payments is the United Kingdom instant payment system for pound payments, settling in seconds, 24 hours a day, usually for amounts up to 1 million pounds. For example, a 10,000 euro payment from Paris to Berlin should use SEPA, a 10,000 pound payment from London to Manchester should use Faster Payments, and a 10,000 dollar payment from London to Tokyo should use SWIFT. The cost also differs, with SEPA and Faster Payments usually cheaper than a SWIFT cross border payment, which carries correspondent fees. A business analyst should map each payment to the right rail before designing the flow.

TARGET Services is the name for the Eurosystem market infrastructure services that settle euro payments and securities in central bank money. The three main services are T2, which provides RTGS for high value payments and CLM for central bank operations, T2S, which settles securities transactions, and TIPS, which settles instant payments in seconds. Each service has its own accounts and its own message flows, but they share access through ESMIG and they share liquidity through the Main Cash Account, known as the MCA. A bank in Frankfurt can therefore hold liquidity in its MCA, move it to its RTGS Dedicated Cash Account for a EUR 12,000,000 high value payment, move it to its TIPS Dedicated Cash Account for instant payments, and use T2S to settle a EUR 5,000,000 securities trade. The services work together, but a payment in one service does not settle in another, and each service has its own cut off times, its own status reports, and its own rules for queuing and liquidity management.

TARGET2 was the Eurosystem real time gross settlement system that operated before March 2023, and it closed on 20 March 2023 when TARGET T2 went live. The change was not a simple rename, because T2 introduced a new account structure, new ISO 20022 messages, and a split between RTGS for payment settlement and CLM for central bank operations. Under TARGET2, a bank held a single RTGS account that handled both payments and central bank operations. Under T2, the same bank holds an MCA in CLM for central bank operations and liquidity management, and a separate RTGS Dedicated Cash Account for payment settlement. A EUR 25,000,000 payment that would have settled on a TARGET2 RTGS account now settles on a T2 RTGS DCA, while a EUR 40,000,000 liquidity operation with a national central bank settles on the MCA. Banks had to rebuild their interfaces, their liquidity management, and their reconciliation to the new structure before the migration date.

The Main Cash Account, known as the MCA, is the central account that a T2 participant holds in CLM, and it is the hub for liquidity management across TARGET Services. The MCA holds the liquidity that a bank can move to its RTGS Dedicated Cash Account, its TIPS Dedicated Cash Account, and its T2S Dedicated Cash Account, and it is also the account used for central bank operations such as monetary policy operations, standing facilities, and reserve management. A bank in Milan with EUR 180,000,000 in its MCA can move EUR 60,000,000 to RTGS for the morning payment run, EUR 30,000,000 to TIPS for instant payments, and keep EUR 90,000,000 in the MCA for central bank operations later in the day. The MCA is also where a bank receives credit from the central bank and where it pays fees and charges. Because the MCA is the hub, a liquidity shortage in the MCA affects every service, and treasury teams monitor the MCA balance continuously during the business day.

ESMIG is the Eurosystem Single Market Infrastructure Gateway, and it is the single access point through which participants connect to TARGET Services. Instead of building a separate connection for T2, another for T2S, and another for TIPS, a bank connects once through ESMIG and reaches all three services through that gateway. ESMIG supports both application to application communication, known as A2A, for automated message exchange, and user to application communication, known as U2A, for manual work through a graphical interface. A bank in Paris can therefore send a pacs.008 payment to RTGS, a camt.050 liquidity transfer to TIPS, and a securities settlement instruction to T2S, all through the same ESMIG connection, using the same authentication and the same network service provider. ESMIG also handles the routing of messages to the right service, so a message addressed to TIPS is not delivered to RTGS by mistake, and it provides a single point for monitoring connectivity and message status.

TARGET Services are designed for multi currency operation, which means the same technical platform can settle payments in euros and, where agreed, in other currencies. TIPS already settles instant payments in euros and in Swedish kronor, and the design allows other currencies to be added when the relevant central bank joins the service. A bank that offers instant payments in kronor through TIPS holds a TIPS Dedicated Cash Account in kronor, separate from its euro TIPS account, and it manages liquidity for each currency separately. A EUR 8,000 instant payment and a SEK 75,000 instant payment therefore settle on different accounts, in different currencies, with different liquidity, even though they use the same TIPS message flow. Multi currency operation does not mean that a euro payment can settle in kronor, and it does not mean that exchange rates are applied inside TIPS. Each currency settles in its own central bank money, on its own accounts, under the rules of the central bank that issues that currency.

The ECB Guideline is the legal framework that governs TARGET Services, and it sets the rules for participation, for accounts, for liquidity, and for the operation of T2, T2S and TIPS. The Guideline defines who can be a participant, what types of accounts a participant can hold, how settlement finality works, and what happens when a participant fails to meet its obligations. It also defines the roles of the national central banks, which operate the services for participants in their countries, and the role of the European Central Bank, which oversees the system as a whole. A bank in Amsterdam that wants to join T2 must meet the participation criteria in the Guideline, open an MCA and the relevant Dedicated Cash Accounts, and agree to the terms for liquidity, for queuing, and for the use of ESMIG. The Guideline is the reason that T2 rules are consistent across countries, so a EUR 10,000,000 payment from a bank in Lisbon to a bank in Helsinki follows the same settlement rules as a payment between two banks in Frankfurt.

T2S is the TARGET Securities Settlement service, and it settles securities transactions in central bank money on Dedicated Cash Accounts that are linked to securities accounts. When a bank in Frankfurt buys EUR 5,000,000 of German government bonds from a bank in Paris, T2S settles the trade by moving the bonds from the seller securities account to the buyer securities account, and by moving EUR 5,000,000 from the buyer T2S DCA to the seller T2S DCA, at the same moment, so neither side can fail without the other side also failing. That simultaneous settlement is called delivery versus payment, and it removes the risk that one side delivers the bonds but does not receive the money. T2S operates on the same TARGET platform as T2 and TIPS, and it shares access through ESMIG and liquidity through the MCA, but it settles securities, not payments, and its messages and its settlement times are different from the payment services. A payment in T2 does not settle a securities trade, and a securities settlement in T2S does not pay a supplier.

CLM and RTGS are the two services inside TARGET T2, and they serve different purposes even though they share the same platform. CLM, or Central Liquidity Management, holds the Main Cash Account and handles central bank operations, such as monetary policy operations, standing facilities, reserve management, and the management of liquidity across TARGET Services. RTGS, or Real Time Gross Settlement, holds the RTGS Dedicated Cash Accounts and settles high value payments in real time, in full, on central bank accounts. A bank in Vienna with EUR 120,000,000 in its MCA uses CLM to manage that liquidity and to take part in a central bank operation, and it moves EUR 50,000,000 to its RTGS DCA to settle a EUR 50,000,000 payment to a bank in Brussels. The payment settles in RTGS, not in CLM, and the central bank operation settles in CLM, not in RTGS. The split lets each service apply its own rules, its own queues, and its own cut off times, while the MCA in CLM remains the hub for moving liquidity between them.

A Direct participant in the RTGS Directory is a bank or institution that holds its own RTGS Dedicated Cash Account in T2 and sends and receives payments directly through ESMIG. The Direct participant is named in the directory with its own BIC, and other banks address payments to that BIC knowing that the payment will settle on that participant account. A bank in Frankfurt with BIC COBADEFFXXX that holds an RTGS DCA is a Direct participant, and a EUR 3,500,000 payment addressed to COBADEFFXXX settles directly on its account. Direct participation gives the bank full control over its liquidity, its queues, and its payment timing, but it also requires the bank to meet the technical, operational and liquidity requirements of T2. A Direct participant must be able to send and receive ISO 20022 messages, manage its intraday liquidity, and respond to central bank operations, and it is responsible for its own settlement risk.

An Indirect participant in the RTGS Directory is a bank or institution that does not hold its own RTGS Dedicated Cash Account, but settles its T2 payments through a Direct participant that acts on its behalf. The Indirect participant is listed in the directory with its own BIC, but payments addressed to that BIC are routed to the Direct participant account for settlement. A small bank in Turin with BIC ABCDITMMXXX might be an Indirect participant through a larger bank in Milan, so a EUR 850,000 payment addressed to ABCDITMMXXX settles on the Milan bank RTGS DCA, and the Milan bank then credits the Turin bank through its own internal accounts. Indirect participation lets smaller banks use T2 without building a full direct connection, but it means the Indirect participant depends on its Direct participant for liquidity, for cut off times, and for status reporting, and it must have a clear agreement on how payments and returns are handled.

A Multi-addressee participant is a Direct participant that allows other institutions to be addressed through its BIC in the RTGS Directory, so that payments to several BICs settle on the same RTGS Dedicated Cash Account. The Multi-addressee arrangement is common in banking groups, where a parent bank holds the RTGS DCA and its branches or subsidiaries are listed as addressees under the parent BIC. A banking group in Paris might hold one RTGS DCA under BIC PARBFRPPXXX, with three subsidiary BICs listed as Multi-addressee entries, so a EUR 1,200,000 payment to any of the three subsidiary BICs settles on the parent RTGS DCA. The parent bank is then responsible for crediting the right subsidiary account internally. Multi-addressee participation reduces the number of RTGS accounts a group must fund, but it requires careful internal accounting, because a payment addressed to a subsidiary BIC settles on the parent account and the parent must not confuse it with its own payment.

An Addressable BIC is a BIC that is listed in the RTGS Directory as reachable through a Direct participant, even though the institution behind that BIC does not hold its own RTGS account. The Addressable BIC lets other banks address a payment to that institution in T2, knowing that the payment will be routed to the Direct participant that sponsors it. A corporate bank in Vienna with BIC WXYZATWWXXX might be an Addressable BIC through a Direct participant in Vienna, so a EUR 420,000 payment addressed to WXYZATWWXXX is routed to the sponsor bank RTGS DCA, and the sponsor bank credits the Vienna bank. The difference from an Indirect participant is one of directory treatment and of the services the institution can use, because an Addressable BIC is primarily a routing entry, while an Indirect participant has a fuller participation status with its own settlement arrangements. Both arrangements depend on the sponsor bank, and both require the sponsor to handle returns, rejections and status reports for the sponsored BIC.

The Business Application Header, known as the BAH, is the head.001 message that sits in front of every ISO 20022 business message, and it names the sender and the receiver of the message as a whole. The instructed agent is a field inside the business message itself, and it names the agent that is instructed to execute the payment. Those two agents can be different, and the difference matters in T2. A payment sent from a bank in Madrid to a bank in Berlin might carry a BAH that names the Madrid bank as sender and the Berlin bank as receiver, while the instructed agent inside the pacs.008 names a third bank in Frankfurt that is instructed to debit an account and forward the payment. The BAH tells the network where the message came from and where it is going, while the instructed agent tells the payment chain who must act on the instruction. A bank that confuses the two can route a EUR 2,000,000 payment to the wrong agent, or report a status to the wrong sender, so operations teams must check both fields separately.

The example COBAESMXXXX and COBADEFFXXX shows how addressing works in T2 when a payment is routed through a sponsor. COBAESMXXXX is the BIC of a Commerzbank entity in Spain, and COBADEFFXXX is the BIC of Commerzbank in Germany, which holds the RTGS account. A payment of EUR 950,000 addressed to COBAESMXXXX does not settle on a Spanish RTGS account, because the Spanish entity does not hold its own RTGS DCA for that payment. Instead, the RTGS Directory shows COBAESMXXXX as reachable through COBADEFFXXX, so the payment is routed to the German bank, settles on the COBADEFFXXX RTGS DCA, and the German bank credits the Spanish entity internally. The BAH of the pacs.008 would name the sender and the receiver of the message, while the instructed agent would name COBADEFFXXX as the agent instructed to settle the payment. The example shows why a BIC alone does not tell you where a payment settles, because the directory entry, not the BIC country code, decides the settlement account.

In CBPR+, a pacs.002 Payment Status Report is mandatory only for a final negative status, which means a bank must send it when a payment is finally rejected and will not be processed further. A bank is not required to send a pacs.002 for every successful payment, and it is not required to send one for an intermediate status that may still change. A USD 180,000 payment from a bank in London to a bank in New York that is rejected because the creditor account does not exist must be reported with a pacs.002 carrying status RJCT and a reason code such as AC03, and that report is mandatory because the rejection is final. A payment that is accepted, or that is pending while a check is completed, does not trigger the same mandatory report. The rule reduces message traffic, because banks do not have to report every acceptance, but it also means the sender must know that silence does not always mean acceptance, and it must use tracking and its own reconciliation to confirm that a payment without a pacs.002 has settled.

A pacs.004 Payment Return is a separate settlement instruction, not a copy of the original pacs.008, and it moves funds back from the returning agent to the previous agent in the chain. When a bank returns a payment, it creates a new pacs.004 message with its own message identification, its own settlement date, and its own amount, and it sends that message as a new instruction that settles on the accounts of the banks in the return chain. A USD 250,000 payment from a bank in Singapore to a bank in Frankfurt that cannot be applied because the creditor account is closed would be returned with a pacs.004 for USD 250,000, or for a lower amount if charges have been deducted. The pacs.004 carries the original end to end identification and the original UETR, so the return can be linked to the original payment, but it is settled as a new payment in its own right, with its own status reports and its own reconciliation. Treating the return as a copy would miss that settlement, and it would leave the accounts out of balance.

A pacs.004 return can carry a different amount from the original pacs.008, and the difference is usually caused by charges deducted along the return chain. When a payment is returned, each agent in the chain may deduct its own charge for handling the return, and the amount that reaches the original sender is the original amount minus those charges. A USD 120,000 payment from a bank in Dubai to a bank in London that is returned because the creditor name does not match might come back as USD 119,950, after a USD 50 charge is deducted by the returning bank. The pacs.004 must state the returned amount clearly, and it must state the charges so the sender can reconcile the difference. The sender cannot expect the full USD 120,000 to return automatically, and its treasury system must be able to match a return of USD 119,950 to the original payment of USD 120,000 using the end to end identification and the UETR. If the return amount were forced to equal the original amount, banks would have no way to recover their return handling costs.

Charges on a return are handled through the Return Chain, which is the sequence of agents that the returned funds pass through on their way back to the original sender. Each agent in the chain can deduct a charge, and the charge information travels with the pacs.004 so every agent knows what has already been deducted and what remains. A EUR 60,000 payment from a bank in Paris to a bank in Tokyo that is returned for a wrong account number might pass through three banks, with each bank deducting EUR 15, so the final return to Paris is EUR 59,955. The Return Chain also determines who is responsible if a return goes missing, because each agent can show that it received the return, deducted its charge, and passed it to the next agent. Without a clear chain, a sender that receives EUR 59,955 instead of EUR 60,000 would not know whether the difference was a legitimate charge, an error, or a loss, and it would have to investigate each bank in the chain separately.

INDA and INGA are return reason codes used in CBPR+ to explain why a payment is being returned, and they point to different problems with the instruction. INDA means the instructed agent does not accept the payment, often because the agent cannot process the currency, the payment type, or the settlement route that was instructed. INGA means the instructed agent is not the correct agent for the payment, often because the payment was routed to the wrong bank or the wrong branch. A USD 90,000 payment sent to a bank in Hong Kong that does not handle USD payments for that customer would be returned with INDA, while a EUR 45,000 payment sent to a bank in Milan that is not the creditor agent for the named account would be returned with INGA. The distinction matters, because INDA tells the sender to change the agent or the service it is using, while INGA tells the sender to correct the routing. Both codes appear in the pacs.004 return, and both must be understood by the operations team that decides whether to correct and resend the payment.

A camt.056 recall may only give DUPL, TECH or FRAD as the reason, and that restriction applies in SEPA and in CBPR+ recall handling. DUPL means the payment was sent twice by mistake, for example when a corporation in Lyon sent the same EUR 28,000 supplier payment twice because its system retried a file. TECH means there was a technical error in the payment, for example when the amount was EUR 280,000 instead of EUR 28,000 because of a decimal error. FRAD means the payment was fraudulent, for example when a payment of EUR 95,000 was sent after a customer account was taken over by a fraudster. A bank cannot use camt.056 with a reason such as CUST or AC04, because those codes belong to other messages and other processes. The restriction keeps recalls narrow, because a recall asks the creditor bank to return funds that have already been credited, and the creditor bank needs a clear and limited set of reasons to decide whether to agree to the return.

A negative camt.029 answer to a recall is restricted to seven codes, and a bank must choose one of them when it refuses to return the funds. AC04 means the account is closed, so the funds cannot be debited from the creditor account. AM04 means there are insufficient funds, so the creditor account does not hold enough to cover the return. ARDT means the payment has already been returned, so a second return would duplicate the first. CUST means the customer refused the return, so the creditor does not agree to give the money back. LEGL means there is a legal reason, such as a court order, that prevents the return. NOAS means no answer from the customer, so the creditor bank could not get a decision in time. NOOR means no original payment, so the creditor bank cannot find the payment that is being recalled. A EUR 60,000 recall that is refused with AM04 tells the sender that the creditor account holds less than EUR 60,000, while a refusal with CUST tells the sender that the creditor has refused, and the two refusals need different follow up.

A TIPS SCT Inst payment is an instant euro payment that settles in seconds on TIPS Dedicated Cash Accounts, and it follows the SEPA Instant Credit Transfer scheme. The debtor bank sends a pacs.008.001.08 to TIPS, TIPS validates the message, reserves the funds on the debtor bank TIPS DCA, and forwards the payment to the creditor bank. The creditor bank has a short time, normally 20 seconds, to accept or reject the payment, and if it accepts, TIPS settles the payment by moving the reserved funds to the creditor bank TIPS DCA. A EUR 4,500 payment from a bank in Berlin to a bank in Rome can therefore move from the debtor account to the creditor account in under 10 seconds, including the time for validation, reservation, acceptance and settlement. If the creditor bank does not respond in time, the payment expires and the reserved funds are released back to the debtor bank. The whole flow is designed for speed, and every step has a strict time limit.

A TIPS Non-Euro instant payment is an instant payment in a currency other than the euro that settles on TIPS, and the best known example is the Swedish krona. The flow is the same as for a euro SCT Inst payment, with validation, reservation, acceptance and settlement, but the payment settles on a TIPS Dedicated Cash Account in kronor, not in euros. A SEK 120,000 payment from a bank in Stockholm to a bank in Gothenburg is validated by TIPS, the funds are reserved on the debtor bank kronor TIPS DCA, the creditor bank accepts, and TIPS settles the payment by moving the reserved kronor to the creditor bank TIPS DCA. The liquidity for the payment must be in kronor, and the debtor bank must manage its kronor liquidity separately from its euro liquidity. Non-Euro operation shows that TIPS is a multi currency platform, not a euro only platform, and it allows other central banks to join TIPS for their own currencies without building a separate instant payment system from scratch.

SIP is the Single Instructing Party model in TIPS, and it allows a single party to instruct instant payments on behalf of other participants. Under SIP, a bank or a service provider acts as the instructing party for several banks, sending pacs.008 messages to TIPS and receiving pacs.002 reports on their behalf. A banking group in Amsterdam might use SIP so that its central payments hub sends all instant payments for its subsidiaries in Belgium, Germany and France, instead of each subsidiary building its own TIPS connection. The hub must be authorised by each subsidiary, and it must be able to identify which subsidiary each payment belongs to, so that settlement is recorded on the right TIPS DCA. SIP reduces the technical burden on smaller banks, because they can offer instant payments through a single hub, but it concentrates operational risk in the hub, so the hub must have strong controls, clear agreements, and a tested fallback if its connection to TIPS fails.

A TIPS instant payment moves through seven statuses, and each status tells the banks exactly where the payment stands. Received means TIPS has received the pacs.008 and has started to process it. Validated means the message has passed format and business checks and is ready for reservation. Reserved means TIPS has reserved the funds on the debtor bank TIPS DCA, so the money cannot be used for another payment while the creditor bank decides. Settled means the creditor bank accepted and TIPS has moved the reserved funds to the creditor bank TIPS DCA. Failed means the payment could not be completed, often because validation failed or the funds could not be reserved. Expired means the creditor bank did not respond within the time limit, so TIPS released the reservation. Rejected means the creditor bank actively refused the payment, for example because the creditor account does not exist. A EUR 2,800 payment that is Reserved and then Settled has completed, while a payment that moves from Reserved to Expired has not moved any money at all.

In TIPS, a pacs.008.001.08 is the instant payment message that carries the instruction from the debtor bank to the creditor bank, and a pacs.002.001.10 is the status report that tells the sender what happened to that instruction. The debtor bank sends the pacs.008 to TIPS with the debtor, the creditor, the amount, the currency, and the end to end identification. TIPS validates the pacs.008, reserves the funds, and forwards it to the creditor bank, which must accept or reject it within the time limit. TIPS then sends a pacs.002.001.10 to the debtor bank, and to the creditor bank where relevant, reporting whether the payment was settled, failed, expired or rejected. A EUR 6,300 payment from a bank in Vienna to a bank in Athens is therefore a single pacs.008 that produces a pacs.002 with status ACCP or RJCT, and the debtor bank uses that pacs.002 to update its customer. The version numbers matter, because TIPS expects pacs.008.001.08 and pacs.002.001.10, and an older version would be rejected at validation.

TIPS liquidity transfers use the deposit model, which means a bank must hold funds on its TIPS Dedicated Cash Account before it can send an instant payment, and it cannot settle a payment by borrowing from the central bank at the moment of settlement. The bank deposits liquidity into its TIPS DCA in advance, either from its MCA or from its RTGS DCA, and TIPS settles instant payments only up to the balance on that TIPS DCA. A bank in Lisbon that expects EUR 50,000,000 of instant payments in a day must deposit at least that amount into its TIPS DCA before the day starts, and it must monitor the balance as payments settle and reduce it. If the TIPS DCA runs out of funds, new instant payments will fail at reservation, even if the bank holds EUR 200,000,000 in its MCA, because the funds have not been moved to TIPS. The deposit model makes settlement risk clear, because TIPS never creates money, it only moves money that is already on deposit.

TIPS liquidity transfers follow three rules that every bank must understand before it moves funds. First, a liquidity transfer moves funds between a TIPS Dedicated Cash Account and another account, such as an MCA or an RTGS DCA, and it does not create or destroy liquidity, it only moves it. Second, a liquidity transfer must be instructed by the account holder or by an authorised party, and it must be validated by TIPS before it settles, so an unauthorised transfer cannot move EUR 10,000,000 out of a TIPS DCA. Third, a liquidity transfer settles immediately and in full, and it cannot be partially settled, so a transfer of EUR 25,000,000 either moves the full amount or it fails and no money moves. A bank in Dublin that moves EUR 25,000,000 from its RTGS DCA to its TIPS DCA in the morning, and moves EUR 15,000,000 back to its MCA in the evening, is following all three rules, and its treasury team can reconcile the TIPS DCA balance at the end of the day by adding the inbound transfer and subtracting the outbound transfer and the instant payments.

Liquidity transfers in TIPS use three camt messages, and each one has a distinct role. A camt.050.001.04 Liquidity Credit Transfer is the instruction to move liquidity, for example from an MCA to a TIPS DCA, or from a TIPS DCA to an RTGS DCA. A camt.025.001.05 Receipt is the confirmation that TIPS has received and processed the liquidity transfer, and it tells the sender that the transfer has settled. A camt.054.001.04 Bank to Customer Debit Credit Notification is the notification that a TIPS DCA has been debited or credited, so the bank can update its own ledger and reconcile its balance. A bank in Helsinki that moves EUR 30,000,000 from its MCA to its TIPS DCA sends a camt.050, receives a camt.025 confirming settlement, and receives a camt.054 showing the credit to its TIPS DCA. The three messages together give the bank an instruction, a confirmation, and a notification, and the bank needs all three to prove that its liquidity moved correctly.

A2A and U2A are the two ways a bank can communicate with TARGET Services, and they serve different purposes. A2A, or application to application, is automated message exchange between the bank system and the TARGET system, using ISO 20022 messages sent through ESMIG. A bank that sends 20,000 instant payments a day uses A2A, because no person could type that many pacs.008 messages by hand. U2A, or user to application, is manual work through a graphical interface, where a person logs in, views balances, enters a liquidity transfer, and checks the status of a payment. A treasury manager in Madrid who moves EUR 18,000,000 from an MCA to a TIPS DCA through the screen is using U2A, while the bank system that sends the camt.050 automatically at 7 am is using A2A. Both channels reach the same TARGET Services, but A2A is for volume and automation, and U2A is for control, for investigation, and for work that needs a human decision.

A TIPS Dedicated Cash Account, known as a TIPS DCA, is an account held by a bank or a payment service provider for settling instant payments on TIPS, and it holds the funds that are reserved and settled for each instant payment. An AS Technical Account is an account held by an Ancillary System, such as a clearing house or a securities settlement system, for settling the net obligations of its participants through TIPS or T2. A bank in Frankfurt holds a TIPS DCA in its own name and uses it for its own instant payments, while a clearing house holds an AS Technical Account and uses it to settle the net instant payment obligations of all its member banks in one transfer. A EUR 7,500 instant payment settles on the bank TIPS DCA, while a EUR 45,000,000 net settlement for a clearing house settles on the AS Technical Account. The difference matters for liquidity, because a bank must fund its own TIPS DCA, while an Ancillary System must fund its Technical Account from the contributions of its participants.

Transit Accounts in TIPS are accounts used to hold funds temporarily while they move between services or between currencies, and they are not the final settlement account for a payment. When liquidity moves from a TIPS DCA in euros to a TIPS DCA in another currency, or when funds move between TIPS and another TARGET service, the funds may pass through a Transit Account so that the movement can be recorded and reconciled. A bank in Stockholm that moves SEK 40,000,000 from its TIPS DCA to its RTGS account might see the funds pass through a Transit Account for a short time, and the Transit Account balance should return to zero once the transfer is complete. Transit Accounts are not customer accounts, and a bank cannot use a Transit Account to make a payment to a creditor. They are internal accounts of the TARGET system, and their purpose is to make the movement of liquidity visible and auditable, so that a treasury team can trace a EUR 20,000,000 transfer from its MCA to its TIPS DCA through every step.

An inbound liquidity transfer in TIPS is a transfer that moves funds into a TIPS Dedicated Cash Account, from an MCA, an RTGS DCA, or another account outside TIPS. An outbound liquidity transfer moves funds out of a TIPS DCA, to an MCA, an RTGS DCA, or another account. A bank in Rome that moves EUR 35,000,000 from its MCA to its TIPS DCA at the start of the day is making an inbound transfer, because the funds are coming into TIPS. The same bank that moves EUR 22,000,000 from its TIPS DCA back to its MCA at the end of the day is making an outbound transfer, because the funds are leaving TIPS. Inbound transfers increase the amount available for instant payments, while outbound transfers reduce it, and the bank must balance the two so that it has enough liquidity for the day without leaving excess funds idle on the TIPS DCA overnight. Both types use camt.050 for the instruction and camt.025 for the receipt, and both settle immediately and in full.

pain.001.001.09 is the ISO 20022 Customer Credit Transfer Initiation message, and it is the message a customer uses to instruct its bank to make a credit transfer. The message carries the debtor, the debtor account, the creditor, the creditor account, the amount, the currency, the requested execution date, the charge bearer, and the remittance information. A single pain.001 file can contain many instructions under one group header, so a corporation in Munich can send 400 supplier payments worth EUR 2,800,000 in one file, with each payment identified by its own instruction identification and end to end identification. Version .09 is the current version used in the customer to bank space, and it replaces earlier versions that carried fewer fields and less structured remittance information. Banks validate the .09 file for format, for business rules, and for funds, and they report the outcome in a pain.002.001.10 status report, so the customer knows which payments were accepted and which were rejected.

pain.002.001.10 is the ISO 20022 Customer Payment Status Report, and it is the reply a bank sends to its customer after it receives a pain.001 file. The report tells the customer whether each instruction was accepted, rejected, or is still pending, and it gives a reason code when an instruction fails. A pain.002 can report at group level, saying the whole file was accepted or rejected, or at transaction level, giving a status for each individual payment. A file with 180 payments can therefore show 178 accepted and 2 rejected, with a separate reason for each rejection, such as AC01 for a wrong account number or AM09 for a wrong amount. The most common statuses are ACCP for accepted, RJCT for rejected, PDNG for pending, and ACSP for accepted settlement in process. Without pain.002, a corporate treasury team would have no reliable way to know whether a EUR 250,000 payment to a supplier in Lyon had been accepted or had been stopped, and it could not correct and resend a failed payment quickly.

In the pain.001 relay scenario, a customer sends its pain.001 file to Bank A, but Bank A does not hold the debtor account, so it cannot debit the customer and cannot create the pacs.008 itself. Bank A acts as a relay, checking the file and forwarding the instruction to the debtor agent, which is the bank that holds the account. A corporation in Amsterdam might hold its EUR account with a bank in Frankfurt, but use a bank in Amsterdam as its payment platform, so it sends a EUR 180,000 payment to the Amsterdam bank, which forwards it to Frankfurt. The Frankfurt bank checks the account, debits EUR 180,000, creates a pacs.008, and sends it to the creditor agent. Status reports flow back through the Amsterdam bank, so the corporation receives a single pain.002 chain even though two banks handled the payment. Relay works only when the agreement between the banks is clear, because Bank A is responsible for first line validation and forwarding, while the debtor agent is responsible for the debit and for creating the pacs.008.

Authorised party initiation allows a party other than the debtor to send a pain.001 instruction on the debtor behalf, provided that party has been authorised to do so. The authorised party might be a payroll service provider, a treasury service company, or a subsidiary that manages payments for a parent company. The pain.001 file names the debtor whose account will be debited, and it also names the initiating party that created the file, so the bank can see that the instruction came from an authorised third party. The debtor agent must check the authorisation before it executes the instruction, using a mandate that names the authorised party, the accounts it may use, the currencies it may pay in, and any amount limits. If a payroll provider is authorised to pay salaries up to EUR 1,000,000 per month, a file for EUR 1,400,000 must be rejected or escalated. The bank reports the outcome in pain.002, with a reason code that points to the authorisation problem when the instruction is rejected.

Financial Institution Payment Initiation is a form of initiation in which one bank instructs another bank to make a payment, rather than a customer instructing its own bank. The initiating bank sends the instruction in a pain.001 format or in an equivalent format, and the receiving bank treats it as an instruction to debit a specified account and to create the onward payment. A small bank in Lisbon might instruct its correspondent bank in London to pay USD 95,000 to a beneficiary in Singapore, because the Lisbon bank holds a USD account with the London bank but has no direct USD clearing route. The London bank debits the Lisbon bank USD account, creates a pacs.008, and sends it through the correspondent chain to Singapore. The London bank reports the outcome to the Lisbon bank, and the Lisbon bank reports to its customer, so each bank in the chain knows only its own leg. Financial institution initiation is common in correspondent banking, where smaller banks rely on larger banks for currencies and routes they do not clear directly.

Settlement completes the interbank transaction on accounts, and it is the moment when the payment becomes final and irrevocable between banks. A payment instruction is not settlement, because the instruction only tells a bank what to do, while settlement is the actual movement of value on the accounts of the banks involved. When a bank in Paris pays EUR 5,000,000 to a bank in Madrid through TARGET, settlement happens when the Paris bank RTGS account is debited and the Madrid bank RTGS account is credited, and at that moment the Madrid bank owns the funds and can use them. Before settlement, the payment can still be queued, rejected, or cancelled, but after settlement it cannot be undone by a simple message, it can only be reversed by a new payment or a return. That is why central bank settlement is so important, because settlement on central bank accounts is final, and it removes the credit risk between the two banks.

RTGS settlement on central bank accounts means that a high value payment settles by debiting the debtor bank account at the central bank and crediting the creditor bank account at the same central bank, in real time and in full. A EUR 18,000,000 payment from a bank in Frankfurt to a bank in Milan through TARGET settles when the Frankfurt bank RTGS DCA is debited by EUR 18,000,000 and the Milan bank RTGS DCA is credited by the same amount, and both accounts are held at their national central banks within the Eurosystem. Because the settlement asset is central bank money, the creditor bank faces no credit risk on the debtor bank, and the payment is final as soon as the accounts are updated. RTGS settlement is different from deferred net settlement, where payments are collected and settled in a net batch at the end of the day, because RTGS settles each payment individually, in real time, as soon as funds are available. That immediacy is why RTGS is used for high value and time critical payments.

A TARGET payment between two countries is not a CBPR+ cross border payment, because TARGET is a domestic euro payment system for the euro area, even when the two banks are in different countries. A EUR 7,000,000 payment from a bank in Lisbon to a bank in Helsinki settles on TARGET in central bank money, under the same rules as a payment between two banks in Lisbon, and it is treated as a euro area payment, not as a cross border payment in the CBPR+ sense. A CBPR+ cross border payment is a payment that crosses currency zones or correspondent banking networks, for example a USD 2,000,000 payment from a bank in London to a bank in Tokyo, which moves through correspondent banks and settles on commercial bank accounts, not on a single central bank system. The distinction matters for message rules, for charges, and for tracking, because a TARGET payment uses T2 rules and a UETR is not required, while a CBPR+ payment uses CBPR+ rules, requires a UETR, and follows the correspondent chain. Calling a TARGET payment a cross border payment would apply the wrong rules to it.

When a US dollar payment moves between two banks that do not hold accounts with each other, it moves through correspondent banks, and different USD correspondents can create different Fedwire legs. A USD 400,000 payment from a bank in Dubai to a bank in New York might go through a correspondent in London, which sends a Fedwire payment to the New York bank, while a second USD 400,000 payment from a bank in Singapore to the same New York bank might go through a correspondent in Frankfurt, which sends a separate Fedwire payment. Each correspondent creates its own Fedwire leg, with its own pacs.008, its own settlement on Fedwire, and its own charges, even though the final beneficiary is the same. The sender must therefore know which correspondent its bank uses for USD, what charges that correspondent will deduct, and how long its Fedwire leg will take. A payment that looks identical at the customer level can take a different route, incur different charges, and settle at a different time, depending on the correspondent chain that the sending bank has chosen.

SEPA SCT and SCT Inst use the 2025 implementation guides that took effect on 5 October 2025, with pacs.008.001.08 for the credit transfer, pacs.004.001.09 for the return, and pacs.002.001.10 for the status report. A EUR 12,000 SEPA payment from a bank in Paris to a bank in Berlin is therefore a pacs.008.001.08, and if it is returned it is a pacs.004.001.09, and if its status is reported it is a pacs.002.001.10. The SEPA charge bearer is SLEV only, which means charges are shared under the scheme rules, and a recall uses camt.056 with a reason that may only be DUPL, TECH or FRAD. A bank that sends a SEPA payment with pacs.008.001.07 or with a charge bearer of DEBT would be rejected, because the version and the charge bearer do not match the 2025 guides. The versions are the same across SCT and SCT Inst, but the timing differs, because SCT settles on a same day or next day basis while SCT Inst settles in seconds through TIPS or another instant clearing system.

Swift CBPR+ uses pacs.008.001.08 for customer and interbank credit transfers, and it uses a single transaction profile, which means each pacs.008 carries one payment, not a batch of payments. Every CBPR+ pacs.008 must carry a UETR, which is a unique end to end transaction reference that lets every bank in the correspondent chain track the payment. A USD 750,000 payment from a bank in London to a bank in Hong Kong is therefore a single pacs.008.001.08 with a UETR, and each bank that handles it can look up the UETR to see where the payment stands. The charge bearer in CBPR+ may be DEBT, CRED or SHAR, which gives the sender a choice that SEPA does not allow, and the return uses pacs.004 with the same version family. A bank that sends a CBPR+ payment without a UETR, or with a batch of payments in one pacs.008, would be rejected, because the CBPR+ profile requires one transaction and one UETR per message.

Fedwire Funds went live with ISO 20022 on 14 July 2025, and it uses pacs.008.001.08 for the payment and pacs.004.001.10 for the return, with the head.001.001.03 business application header on its messages. A USD 3,000,000 Fedwire payment from a bank in Chicago to a bank in New York is therefore a pacs.008.001.08 with a head.001.001.03 header, and it settles in real time on central bank accounts at the Federal Reserve. If the payment cannot be applied, it is returned with a pacs.004.001.10, which is a different return version from the pacs.004.001.09 used in SEPA and CHAPS. A bank that sends a Fedwire payment with the wrong header version, or with a pacs.004.001.09 return, would be rejected, because Fedwire expects head.001.001.03 and pacs.004.001.10. The Fedwire migration was a major change for US banks, because it moved Fedwire from its legacy format to ISO 20022, and it aligned Fedwire message versions with the versions used on other rails, while keeping Fedwire specific header and return rules.

FedNow uses pacs.008.001.08 for the instant payment, pacs.004.001.10 for the return, and pacs.002.001.10 for the status report, and it has no REST endpoint for sending a payment, so banks must connect through the FedNow service channels rather than a simple web call. A USD 9,500 FedNow payment from a bank in Dallas to a bank in Miami is therefore a pacs.008.001.08 that settles in seconds, and if it cannot be applied it is returned with a pacs.004.001.10. The pacs.009 message in FedNow is for liquidity transfers only, and it must not be used as a customer payment, because a pacs.009 moves liquidity between accounts, not money to a beneficiary. A bank that tries to send a customer payment as a pacs.009, or that tries to use a REST call to send a payment, would fail, because FedNow does not offer that route. The FedNow versions match the Fedwire pacs.008 and pacs.004 versions, but the services are different, because Fedwire is for high value same day payments and FedNow is for instant payments in seconds.

CHAPS went live with ISO 20022 on 19 June 2023, and it uses pacs.008.001.08 for the payment, pacs.004.001.09 for the return, and pacs.002.001.10 for the status report, with the head.001.001.02 business application header on its messages. A GBP 4,500,000 CHAPS payment from a bank in London to a bank in Edinburgh is therefore a pacs.008.001.08 with a head.001.001.02 header, and it settles in real time on central bank accounts at the Bank of England. If the payment cannot be completed, it is returned with a pacs.004.001.09, and its status is reported with a pacs.002.001.10. A bank that sends a CHAPS payment with the head.001.001.03 header used by Fedwire, or with a pacs.004.001.10 return, would be rejected, because CHAPS expects head.001.001.02 and pacs.004.001.09. The CHAPS migration was the first major ISO 20022 migration for a high value system in the UK, and it set the pattern for the later Fedwire migration in 2025.

TARGET T2 went live with ISO 20022 on 20 March 2023, replacing TARGET2, and it uses pacs.008.001.08 for credit transfers, pacs.004.001.09 for returns, and pacs.002.001.10 for status reports. A EUR 22,000,000 T2 payment from a bank in Frankfurt to a bank in Paris is therefore a pacs.008.001.08 that settles on RTGS Dedicated Cash Accounts, and if it is returned it is a pacs.004.001.09. Liquidity transfers in T2 use camt.050.001.04 for the instruction and camt.025.001.05 for the receipt, so a EUR 40,000,000 move from an MCA to an RTGS DCA is a camt.050, not a pacs message. The T2 versions match the SEPA and CHAPS pacs versions, but the T2 rules are different, because T2 settles on central bank accounts in real time, while SEPA settles through clearing systems. A bank that applies SEPA rules to a T2 payment, or T2 rules to a SEPA payment, would make errors in cut off times, in liquidity management, and in status reporting, even though the message version is the same.

The charge bearer in CBPR+ may be DEBT, CRED or SHAR, while in SEPA it may only be SLEV, and that difference is one of the clearest examples of the same message carrying different rules by rail. DEBT means the debtor pays all charges, so a USD 100,000 payment with DEBT would be debited for USD 100,000 plus charges, and the creditor would receive the full USD 100,000. CRED means the creditor pays all charges, so the creditor would receive USD 100,000 minus charges. SHAR means the charges are shared, with the debtor paying its own bank charges and the creditor paying its own bank charges. SLEV means charges are shared by service level agreement, which is the SEPA rule, and it does not allow the sender to choose DEBT or CRED. A bank that sends a SEPA payment with DEBT would be rejected, while a bank that sends a CBPR+ payment with SLEV would also be wrong, because CBPR+ does not use SLEV. The charge bearer must therefore be set by rail, not just by message version.

The same message and the same version can carry different rules by rail, and that is one of the most important lessons in ISO 20022. A pacs.008.001.08 is used in SEPA, in CBPR+, in Fedwire, in FedNow, in CHAPS, and in T2, but the rules for that message differ on each rail. In SEPA, the charge bearer must be SLEV, the recall reason must be DUPL, TECH or FRAD, and the payment settles through SEPA clearing. In CBPR+, the charge bearer may be DEBT, CRED or SHAR, the payment must carry a UETR, and it settles through the correspondent chain. In Fedwire, the header must be head.001.001.03 and the return is pacs.004.001.10, while in CHAPS the header must be head.001.001.02 and the return is pacs.004.001.09. A EUR 200,000 payment and a USD 200,000 payment can therefore use the same pacs.008.001.08 version and still follow completely different rules, and a bank must check the rail guide, not just the message version, before it sends the payment.

An IBAN, or International Bank Account Number, is a standardised account identifier that lets a payment be routed to the correct account in another country without manual repair. It has three parts: a two letter country code, two check digits, and a Basic Bank Account Number, known as the BBAN, which holds the domestic account details. The total length varies by country, from 15 characters in Norway to 34 in Malta, and the maximum length is 34 characters. A German IBAN, for example, is 22 characters: DE for Germany, two check digits, an eight digit bank code, and a ten digit account number. A French IBAN is 27 characters and includes the bank code, branch code, account number and two check digits inside the BBAN. The structure is defined by the ISO 13616 standard, and each country publishes its own BBAN layout, so a system must know the country specific format before it can validate an IBAN. When a customer enters an IBAN, the bank checks the country code, the length for that country, the character set, and the check digits before the payment is released. An IBAN that fails any of these checks is returned for repair, because sending a payment to a wrongly formed account number risks misdirecting the funds.

The two check digits in an IBAN are calculated with the mod-97 algorithm, which is the same method used to verify that an IBAN has not been mistyped. The check is performed in four steps. First, the IBAN is rearranged by moving the first four characters, the country code and the two check digits, to the end of the string. Second, every letter is converted to a number, where A equals 10, B equals 11, and so on up to Z equals 35. Third, the resulting long number is divided by 97 and the remainder is taken. Fourth, if the remainder is 1, the IBAN is valid. Take the German IBAN DE89 3704 0044 0532 0130 00. Moving DE89 to the end and converting the letters gives a long number, and dividing that number by 97 leaves a remainder of 1, so the IBAN passes the check. If a single digit is mistyped, the remainder changes and the check fails, which is why banks run this validation before a payment is sent. The mod-97 check catches most typing errors, including transposed digits and a wrong country code, but it does not prove that the account exists or that it belongs to the named beneficiary. A valid IBAN can still belong to the wrong person, so banks combine the checksum with separate payee verification checks.

An on-us transaction is a payment where the sender and the receiver hold accounts at the same bank, or at banks in the same banking group, so the money never leaves the institution. When a customer of Northbridge Bank sends 5,000 pounds to another customer of Northbridge Bank, the bank simply debits one account and credits the other in its own core banking system, with no clearing system and no correspondent bank involved. The payment settles immediately, costs the bank almost nothing, and carries very little settlement risk, because no external party has to deliver the funds. Within an intrabank group, the same idea applies across subsidiaries: a payment from a customer of the parent bank in London to a customer of its subsidiary in Dublin is still on-us if the group settles it internally through its own books, though the group must still respect the legal separation between the two entities and record the intercompany position correctly. On-us payments still need validation, sanctions screening, fraud checks and audit logging, because the regulatory duties do not disappear when the money stays inside the bank. The difference is in the settlement path: the bank can confirm the payment instantly, give the customer immediate certainty, and reconcile it the same day without waiting for an external clearing file.

In the four-corner model, a large company acts as the debtor or the creditor in a payment, and its needs are very different from those of a private customer. A large company, such as a multinational manufacturer, makes high value payments to suppliers in many countries, receives payments from customers in many currencies, and manages its cash through a treasury team rather than through a branch visit. It needs bulk payment files, payment initiation through an API or a treasury management system, multi-currency accounts, and detailed status reporting so that its enterprise system can reconcile every payment automatically. A payment of 2 million dollars from a car manufacturer in Stuttgart to a parts supplier in Detroit must carry structured remittance information, such as the invoice numbers, so that the supplier can match the payment to the right invoices without manual work. The company also needs cutoffs per corridor, approval workflows for large amounts, and foreign exchange services for converting receipts into its home currency. For the bank, a large corporate customer is a high value relationship that justifies dedicated service, custom pricing and direct integration, and the payment service must be built around the company treasury workflow rather than around a retail banking app.

In the four-corner model, a private customer is an individual who sends or receives a payment for personal reasons, and the payment service must be simple, fast and safe enough for someone with no banking knowledge. A private customer sends money to family, pays rent, buys goods online, or receives a salary, and each of these payments is usually small in value but high in volume across the bank. A payment of 250 euros from a customer in Paris to her sister in Madrid must be easy to initiate from a mobile app, must arrive quickly, and must give a clear confirmation, because the customer has no treasury team to chase a missing payment. The bank must protect the private customer with strong authentication, clear fee disclosure, and fraud checks that catch scams without blocking genuine payments. Private customers also benefit from services such as confirmation of payee, which checks that the name entered matches the account holder, and from instant payment rails that settle in seconds. For the bank, private customers are served through standardised products, digital channels and self service, and the payment journey must work the first time, because a failed payment creates a support call and a loss of trust that is hard to win back.

In the four-corner model, a small or medium enterprise, known as an SME, sits between the private customer and the large company: it has business payment needs, but it does not have a treasury department. An SME, such as a family run engineering firm in Manchester with 40 employees, pays suppliers, pays salaries, collects from customers and manages its cash through its owner or a small finance team. It needs same-day or next-day supplier payments, bulk payroll files, and clear status information, but it cannot afford the custom integration that a large company uses. A payment of 18,000 pounds from the engineering firm to a steel supplier in Sheffield must be easy to create in internet banking, must carry the invoice reference, and must be confirmed the same day so that the supplier releases the goods. SMEs are also sensitive to fees and to cutoffs, because a missed cutoff can delay a delivery and disrupt production. For the bank, SMEs are a large and valuable segment that is best served with standardised products, simple digital channels, and support that understands business cash flow. The payment service for an SME must therefore balance ease of use with the controls that a business needs, such as dual authorisation for larger amounts and limits per user.

In the four-corner model, associations and non-governmental organisations, known as NGOs, are end parties whose payments are driven by their mission rather than by profit. An association, such as a trade body collecting membership fees, receives many small payments from members and makes payments for events, publications and staff. An NGO, such as a charity funding health programmes, receives donations from many sources and disburses grants to partners in other countries, often in currencies and corridors where the banking infrastructure is thin. A payment of 50,000 dollars from a charity in London to a health partner in Nairobi must carry clear remittance information, must be screened carefully, and must be traceable, because donors and regulators expect full transparency about where the money went. Associations and NGOs often work with volunteers or small finance teams, so they need simple payment tools, low fees, and clear reporting that supports their audit and annual accounts. They may also be subject to extra due diligence, because banks must manage the risk of funds being diverted, so the onboarding and the ongoing monitoring are more detailed than for a private customer. For the bank, these customers need a service that is both simple to use and strong on control and reporting.

A wash account, also called a suspense or transit account, is an internal account that a bank uses to hold funds temporarily while a payment is being processed, reconciled or investigated. The money in a wash account belongs to a customer or to another bank, but it has not yet reached its final destination, so the bank records it separately from its own funds. For example, when a cross-border payment of 100,000 dollars arrives at a bank and the beneficiary account details are incomplete, the bank credits the amount to a wash account while operations contacts the beneficiary bank for the correct details. Once the details are confirmed, the amount is moved from the wash account to the beneficiary account, and the wash account balance returns to zero. Wash accounts are also used during a system migration, when payments are held briefly while a new system is checked, and in foreign exchange transactions, where one currency is sold and another is bought through a wash account that nets to zero. The key control is that every entry in a wash account must be investigated and cleared quickly, because a balance that sits in a wash account for days usually means a payment is stuck, a reconciliation has broken, or a fraud has occurred. Finance and operations therefore monitor wash account ageing daily.

Canada is modernising its payment systems through a programme led by Payments Canada, which operates the national clearing and settlement infrastructure. The centrepiece is the Real-Time Rail, known as RTR, which will let Canadians send and receive payments in seconds, 24 hours a day, with rich remittance data attached. Alongside the new rail, Canada is replacing its legacy batch systems: the Automated Clearing Settlement System, known as ACSS, and the Large Value Transfer System, known as LVTS, are being retired in favour of modern platforms built on ISO 20022 messaging. The Lynx high value system, which went live in 2021, already settles large payments in central bank money using ISO 20022, and it replaced LVTS. The modernisation also includes the move to ISO 20022 across retail and high value payments, so that payment data is structured, consistent and easier to screen, reconcile and report. For a business analyst, the Canadian programme is a useful case study because it shows a whole country moving from batch files and proprietary formats to real time, data rich payments, with a staged migration that protects existing services while the new rail is built and tested.

The Canadian modernisation programme affects banks, businesses and technology teams in several practical ways. First, ISO 20022 becomes the common language for payment messages, so banks must map their legacy formats to the new standard, rebuild their interfaces, and train operations staff on structured party and remittance data. Second, the Real-Time Rail changes customer expectations: once instant payments are available, a business that pays a supplier expects the money to arrive in seconds, and a payment that takes a day needs an explanation. Third, the retirement of ACSS and LVTS forces banks to move every payment type to the new platforms, which means a full inventory of payment flows, volumes, cutoffs and downstream systems before any migration can start. Fourth, the richer data in ISO 20022 messages improves fraud detection, sanctions screening and reconciliation, but it also requires stronger data governance, because a field that was free text in the old format is now structured and validated. Finally, the programme is staged over several years, so a bank must run old and new systems side by side, manage dual reporting, and plan its cutover in phases. The lesson for analysts is that modernisation is a business change programme, not a technology upgrade, and it succeeds only when the business case, the customer communication and the testing are planned as carefully as the build.

In TIPS, the Credit Memorandum Balance, known as the CMB, is a mechanism that lets a payment service provider offer instant payments to its customers without holding its own TIPS account. A CMB is a balance that sits on top of a TIPS Dedicated Cash Account, known as a DCA, which belongs to a direct participant. The direct participant, usually a bank, grants a CMB to a reachable party, such as a smaller bank or a payment institution, and sets a limit for it. When the reachable party sends an instant payment, the amount is checked against its CMB limit and, if it passes, the payment settles on the DCA of the direct participant. The CMB therefore gives the reachable party a controlled share of the direct participant liquidity, without giving it direct access to central bank money. For example, a small bank in Portugal may hold a CMB of 2 million euros on the DCA of a larger bank in Frankfurt. Its customers can then send instant payments up to that limit, and the larger bank manages the liquidity and the settlement. The CMB limit can be changed during the day, and the direct participant can block or reduce it if the reachable party breaches its agreement.

The CMB in TIPS is managed through limits, blocking and intraday changes, and the direct participant carries the responsibility for keeping it safe. The direct participant sets the CMB limit when the arrangement is created, and it can increase or decrease the limit during the business day in response to the reachable party payment volumes or its risk position. If the reachable party tries to send a payment that would exceed its CMB limit, TIPS rejects the payment, and the payer receives a negative status report with a clear reason code. The direct participant can also block a CMB entirely, for example if the reachable party fails to fund its position or breaches its contractual terms, and no further payments can be sent against it until the block is lifted. The CMB is also linked to the liquidity on the underlying DCA: the direct participant must hold enough liquidity in its DCA to cover the payments of all its reachable parties, and it can move liquidity between its Main Cash Account and its TIPS DCA during the day. At the end of the day, the CMB balances are not settled separately; they are simply a record of how much of the DCA liquidity each reachable party has used. The direct participant therefore monitors the CMB usage continuously and reconciles it against its own liquidity position.

An instant payment in TIPS between two reachable parties follows a short, tightly timed sequence that completes in seconds. Both parties are reachable parties, which means each one accesses TIPS through a direct participant, either through a CMB or through an instructing party arrangement. The payer bank sends a pacs.008 message to TIPS, which validates the message, checks that both parties are reachable, and checks the payer CMB limit and the liquidity on the payer DCA. TIPS then reserves the amount on the payer DCA and forwards the payment to the payee side. The payee bank must respond within the time limit, which is 20 seconds from the moment the payment was accepted, confirming that it will accept the payment and credit its customer. If the payee confirms in time, TIPS settles the payment by moving the reserved amount from the payer DCA to the payee DCA, and both sides receive a pacs.002 status report confirming settlement. The whole flow is designed so that the payer knows within seconds whether the money has arrived, and the payee can make the funds available to its customer immediately after the confirmation.

The TIPS flow between two reachable parties includes several checks and failure paths that protect both sides when something goes wrong. If the payee bank does not respond within the 20 second window, TIPS times the payment out, releases the reservation on the payer DCA, and sends a negative pacs.002 to the payer, so the money is never lost in transit. If the payee bank rejects the payment, for example because the beneficiary account is closed or the account number is invalid, TIPS releases the reservation and reports the rejection with a reason code that the payer bank can pass to its customer. If the payer CMB limit is insufficient, TIPS rejects the payment before any reservation is made, so no liquidity is tied up. A payment can also fail validation, for example if a mandatory field is missing or the amount exceeds the scheme maximum, and TIPS rejects it immediately with a specific error code. In every failure case, the reservation is released and the funds remain on the payer DCA, which is why the TIPS model is safe: money is only moved when both sides have confirmed. For the business analyst, the key lesson is that the timeout and the reason codes must be built into the customer experience, so that a payer who sees a failure knows whether to retry, correct the details, or contact the bank.

TIPS offers two main settlement options for an instant payment: settlement on a TIPS Dedicated Cash Account, known as a DCA, and settlement through a Credit Memorandum Balance, known as a CMB, which sits on a DCA. When a bank holds its own DCA, it settles directly in central bank money: the payment moves liquidity from the payer DCA to the payee DCA, and the bank manages its own liquidity by moving funds between its Main Cash Account and its TIPS DCA. When a bank is a reachable party without its own DCA, it settles through a CMB granted by a direct participant, and the payment is checked against the CMB limit before it settles on the direct participant DCA. A third option is settlement through an instructing party, where a technical service provider sends and receives messages on behalf of a participant, but the settlement still takes place on the participant DCA. The choice depends on the size of the bank, its payment volumes and its operational capability: a large bank with high volumes normally holds its own DCA, while a smaller bank with low volumes uses a CMB and lets the direct participant manage the liquidity and the TIPS connection.

Choosing between a TIPS DCA and a CMB is a business decision that balances control, cost and risk. A bank that holds its own DCA has full control over its liquidity, can move funds between its Main Cash Account and its TIPS DCA at any time, and can monitor its own settlement position directly. It also bears the full operational burden: it must build and maintain a TIPS connection, manage its liquidity around the clock, and staff a 24 hour operation, because instant payments never stop. A bank that uses a CMB avoids most of that burden, because the direct participant manages the TIPS connection and the liquidity, and the reachable party only needs to manage its CMB limit and its customer facing services. The trade off is dependence: the reachable party can only send payments up to its CMB limit, and it relies on the direct participant to fund the DCA and to keep the service running. If the direct participant has a problem, the reachable party payments stop too. Some banks start with a CMB and move to their own DCA as volumes grow, which is a sensible staged approach. The analyst should document the choice, the limit, the funding arrangement and the fallback plan, so that the business understands what it gains and what it gives up.

A liquidity transfer in TIPS moves funds between a Main Cash Account, known as the MCA, and a TIPS Dedicated Cash Account, known as the DCA, and it can fail for several reasons. The most common failure is insufficient liquidity on the source account: a bank that tries to move 5 million euros from its MCA to its TIPS DCA when the MCA holds only 3 million euros will see the transfer rejected, and the bank must either fund the MCA or reduce the amount. A transfer can also fail because of a validation error, such as a wrong account identifier, a duplicate instruction, or a transfer submitted outside the allowed operating hours for the source system. When a liquidity transfer fails, TIPS sends a negative status report with a reason code, and the liquidity is not moved, so the bank DCA balance is unchanged and no payment is affected directly. The bank must then decide what to do: retry the transfer with a corrected amount, fund the source account from another account, or delay the payments that depended on the liquidity. If the failure happens during a period of high instant payment volumes, the bank may run low on TIPS liquidity and its customer payments may start to fail, so the operations team must monitor DCA balances continuously and set alerts at agreed thresholds. A well run bank keeps a liquidity buffer in its TIPS DCA and has a documented procedure for a failed transfer.

No. The ISO 20022 migration ended MT103 and MT202 for cross-border customer and bank-to-bank payments when coexistence ended on 22 November 2025, but it did not eliminate the MT family. MT messages continue wherever no ISO 20022 replacement was mandated. MT940 customer statements, MT950 statements, MT900 confirmations of debit and MT910 confirmations of credit are still the standard account reporting messages for nostro accounts. MT400 is still used for documentary collections. MT700 and the rest of Category 7 still carry documentary credits and trade finance. MT202 is still used for domestic bank-to-bank transfers inside countries that have not migrated their domestic systems. The correct statement is narrow: for cross-border payments and reporting under CBPR+, the customer payment moved from MT103 to pacs.008 and the bank-to-bank payment moved from MT202 to pacs.009. A business analyst who writes that the MT family has disappeared will mislead developers, testers and operations teams who still receive MT statements every morning.

CBPR+ is the cross-border payments and reporting programme, and its scope is cross-border payments and reporting carried over SWIFT. It is not the whole of SWIFT messaging. SWIFT carries many message families outside CBPR+: Category 7 documentary credits and guarantees, Category 5 securities, Category 3 treasury and foreign exchange, Category 9 cash management and customer status, and the reporting messages MT940, MT950, MT900 and MT910. CBPR+ defines ISO 20022 usage guidelines, message versions and market practice for the cross-border payment chain: pacs.008 for customer payments, pacs.009 for bank-to-bank payments, pacs.002 for status, pacs.004 for returns, camt.056 for cancellations and camt.029 for investigation answers. Domestic payment systems have their own ISO 20022 timelines: Fedwire went live in July 2025, CHIPS in April 2024, CHAPS in June 2023, and SEPA runs its own rulebooks. Confusing CBPR+ with all of SWIFT leads to wrong requirements, because a rule that applies to a cross-border pacs.008 does not automatically apply to a domestic payment or a trade finance message.

Indirect participation is a registered participation type in the T2 RTGS Directory, code 06, but it plays no direct role in euro settlement. An indirect participant holds no RTGS Dedicated Cash Account, so T2 has no account in its name to debit or credit. A EUR 100,000 payment to an indirect participant settles on the direct participant's RTGS DCA, and the direct participant then moves the funds to the indirect participant in its own internal books. From the point of view of T2 settlement, the indirect participant is invisible and only the direct participant balance changes. Indirect participation still has a use: it makes addressing clearer, because a bank can address a payment to the small savings bank that is the real beneficiary while settlement happens on the direct participant account. It adds no new settlement path, no new account and no new liquidity. A bank that moves euro payments in volume becomes a direct participant, code 05, and holds its own RTGS DCA. This treatment follows the TARGET Guideline (EU) 2022/912 and the CRDM RTGS Directory definitions, checked 5 November 2026.

The SEPA Instant Payments Regulation, Regulation (EU) 2024/886, does not impose one universal deadline. Its obligations are phased and they differ by participant type and currency area. Payment service providers in the euro area had to be able to receive instant payments from 9 January 2025 and to be able to send instant payments from 9 October 2025. From October 2025 they must also offer verification of payee, checking that the payee name matches the IBAN before the payment is sent, and they must screen payees against sanctions lists at least daily rather than per transaction. The price of an instant payment must not exceed the price of a regular credit transfer. Payment service providers in EU member states outside the euro area have longer timelines, with receiving required later and sending later still. The regulation applies to euro instant payments, not to all SEPA payments: regular SCT and SDD continue under their own rulebooks. A business analyst must write requirements per obligation and per date, not as a single mandatory date, and must check which obligations apply to each entity in scope.