Contributor archive
Shubham is a payments practitioner whose writing covers payment operations, SWIFT, SEPA, message standards, and transformation work. The pages below turn those topics into structured, plain-language learning guides.
Latest first
A resident individual in India sends dollars to a friend's US account: Form A2 and the Liberalised Remittance Scheme, currency conversion at the sending bank, and a serial MT103 that carries both currencies through one US correspondent to the beneficiary's bank.
Every ISO 20022 payment carries two kinds of metadata: coded fields that declare what the payment is — service level, local instrument, category purpose, purpose — and an agent chain that names who moves it, bank by bank. This article reads a fictional pacs.008 field by field: what each code means, why there are four purpose-ish fields and not one, and how the instructing, previous-instructing, intermediary and reimbursement agents thread a payment across borders.
The move from MT to ISO 20022 is a dated schedule, not a single switch: CBPR+ coexistence from March 2023, CHIPS in 2024, Fedwire's cut-over on 14 July 2025, the end of cross-border MT coexistence in November 2025, mandatory structured or hybrid addresses from 15 November 2026, and later statement-message retirements through 2027-2028.
Uses a hypothetical bank and transaction volumes to estimate the operating economics and potential profitability of domestic and cross-border payment services.
Examines the practical challenges banks face when selecting, implementing, maintaining, and modernizing a payment engine.
Maps the main SEPA Instant exception flows, including pacs.002 rejections, camt.056 recall requests, and pacs.004 returns.
Walks through a successful single SEPA Instant transfer from customer initiation through clearing, status confirmation, and beneficiary credit.
Introduces SEPA Instant transfers, their real-time characteristics, and the European rules expanding availability while constraining fees.
Organizes free online reading into a ten-day study path for building a basic understanding of payment systems.
Curates practical resources for creating a stronger resume when applying for jobs in the payments field.
Offers a short preparation framework for experienced candidates to focus their domain strengths and handle payments-related interview questions.
Directs readers to a detailed learning session about the SWIFT MT103 customer credit transfer message.
Explains how corporates and banks use MT101 transfer requests in practice and how those instructions can lead to customer credit transfers.
Tests foundational payment knowledge with a timed set of questions built around practical domestic and cross-border scenarios.
Provides a timed introductory quiz for readers to check their grasp of essential payments concepts.
Contrasts serial and cover settlement methods by showing how payment instructions and funds travel through correspondent banking chains.
Breaks a SWIFT MT message into its five blocks and explains the identifying, application, content, trailer, and user information they carry.
Explains the MT naming convention, message categories, three-digit identifiers, and other structural details used across SWIFT FIN messages.
Narrows the broader MT catalog to the message categories most relevant to customer transfers, bank transfers, and cash management.
Traces the move from error-prone TELEX instructions to SWIFT's standardized, secure network for exchanging financial messages.
Summarizes the rulebook and operational deadlines for exchanging key SEPA Credit Transfer messages around settlement day.
Compiles a final-stage checklist of common business analyst interview questions and topics for candidate self-assessment.
Explains how an earlier SEPA transfer may be recalled and distinguishes unsettled, positively answered, and negatively answered recall paths.
Shows how a beneficiary PSP sends a pacs.004 along the reverse route when a settled SEPA transfer cannot be completed.
Describes who can reject an SCT before inter-PSP settlement, why rejection occurs, and how status travels back to the originator.
Follows a successful SCT from customer initiation through originator PSP, clearing mechanism, beneficiary PSP, and final account credit.
Collects recommended books and courses for readers who want to deepen their payments and banking knowledge.
Introduces the SCT four-corner model and the roles of the originator, originator PSP, beneficiary PSP, and beneficiary.
Explains how SEPA clearing and settlement mechanisms connect PSPs and distinguishes direct participation from indirect access.
Introduces the ISO 20022 pain, pacs, and camt message families and explains how SEPA schemes adapt them for euro payments.
Defines the difference between a payment scheme and a processing system before introducing SEPA's four principal rule sets.
Organizes the major European institutions, industry bodies, and operational participants that govern and deliver SEPA.
Explains SEPA's purpose, euro-only scope, geographic boundaries, and goal of making cross-border euro transfers resemble domestic payments.
Provides a compact glossary of foundational terms such as SWIFT, SEPA, ISO 20022, payment infrastructures, and related standards.
Explains common payment charge allocations and how foreign-exchange conversion and margins affect cross-currency transfers.
Introduces the bank software that validates, routes, enriches, and processes incoming and outgoing credit transfers at scale.
Assembles a broad question bank candidates can use to test readiness for interviews involving payment-domain knowledge.
Uses debit and credit entries to illustrate how customer, bank, and correspondent accounts reflect the movement of payment funds.
Explains how customer and interbank messages carry payment instructions and status information across an end-to-end transfer.
Identifies the customers, banks, intermediaries, and market infrastructures that initiate, route, settle, and receive payments.
Introduces the author's learning community and its aim to share approachable payments knowledge with industry newcomers.
Uses a simple two-bank example to explain how an online transfer becomes an interbank message and moves through clearing and settlement.
ISO 20022 is an international standard that organises financial messages around business areas, reusable data components, and a shared dictionary, giving families such as pacs, pain, and camt a common structured XML foundation.
The camt (cash management) family reports on accounts and handles payment investigations. It includes intraday reports, end-of-day statements, entry notifications, and the cancellation-request and resolution messages used to recall payments and answer those requests.
CBPR+ (Cross-Border Payments and Reporting Plus) is a set of usage guidelines that apply ISO 20022 to cross-border interbank payments over SWIFT, defining exactly how each message field is populated during and after the MT-to-MX transition.
Message translation converts between legacy MT and ISO 20022 (MX) formats. It preserves core payment data but can truncate the richer structured detail that MX carries, so a full round trip does not always survive intact.
An ACK (acknowledgement) confirms a message was accepted and a NACK (negative acknowledgement) reports it was rejected, while the pacs.002 payment status report tells the sender whether the payment itself was accepted, rejected, or is still pending, with reason codes.
Explains how Verification of Payee compares the beneficiary name a payer enters against the name held on the account before a euro credit transfer is authorised, and what a match, close match, or no match means for the payer.
Describes the pull-payment model of SEPA Direct Debit Core: how a signed mandate authorises collection, how a collection travels as a pain.008 and interbank pacs.003 message, and the roles the creditor and debtor banks play.
Explains how a SEPA Direct Debit collection can fail or unwind — rejects, refusals, returns, refunds, and reversals — including the eight-week no-questions refund window for authorised collections and the thirteen-month window for unauthorised ones.
Explains how a cover payment funds the bank-to-bank leg with a SWIFT MT202 COV while the customer's MT103 travels separately to the beneficiary's bank, and why the cover message must carry the underlying customer details.
Describes the SWIFT Category 9 messages — the MT900 debit confirmation, MT910 credit confirmation, and MT940, MT942, and MT950 statements — and how they feed reconciliation of the accounts a bank holds at other banks.
Explains how banks fund settlement across real-time gross and deferred net systems, what intraday liquidity is, and how payment queues and settlement risk shape when a payment actually moves.
Describes how operations teams triage failed, rejected, and queried payments, how they establish where the funds and settlement stand, and how an investigation case is opened, chased, and closed on evidence.
Explains how banks match internal ledgers against nostro statements and clearing reports to prove recorded money equals actual money, and how unmatched items, called breaks, are found, investigated, and cleared.
Explains where access control, segregation of duties, dual authorization, and screening and fraud checkpoints sit inside payment operations, and how these layered controls protect payments by detecting, reviewing, and escalating what looks wrong.
Breaks down the structure of an International Bank Account Number and a Business Identifier Code, explains how the IBAN's mod-97 check digits work, and shows why validating both catches routing errors early.
Sanctions are legal restrictions on dealing with listed people, entities, and places. Screening is the control that enforces them, checking every customer and payment against official lists before money is allowed to move.
Several authorities issue sanctions: the United Nations, the United States, the European Union, and the United Kingdom among them. Their lists overlap but are not identical, so a bank must decide which regimes its business obliges it to apply.
A designation usually forbids two things: freezing the funds and economic resources of a listed party, and making no funds available to them, directly or indirectly. Narrower sectoral restrictions limit only specific activities rather than freezing everything.
Sanctions screening is a list check with an immediate stop. Anti-money-laundering monitoring looks for suspicious patterns after the fact, and fraud detection protects against theft in real time. The three share data but differ in purpose, timing, and outcome.
The duty to freeze is absolute, but how a bank calibrates its screening, which lists, how sensitive the matching, how often it re-screens, is a set of documented, defensible risk decisions proportionate to the bank's exposure.
A single sanctions list record holds a primary name, aliases, dates and places of birth, nationalities, and identifiers, each tied to a programme tag. This article explains how every field drives a screening match and a defensible review.
Strong secondary identifiers, such as dates of birth, passport numbers, and places, let a screening system confirm or clear a party with confidence. This article explains how good data cuts false positives and what weak data costs.
Authorities publish sanctions lists and change them over time; vendors and feeds carry those additions and removals to screening systems. This article explains the delivery path and why loading updates promptly matters operationally.
Screening vendors merge many official and commercial sources into one combined list. This article explains how aggregation works and why keeping each record's provenance, meaning which authority and which list it came from, is essential for defensible decisions.
Two sanctions controls guard different populations. Customer screening checks the people and entities a bank onboards; transaction screening checks every party named in a payment message in flight. Both are needed because neither control sees what the other sees.
The stages a payment or customer record passes through in a screening engine: normalising the input, generating candidate matches, scoring them against a threshold, disposing of each alert as cleared or escalated, and recording every step for later reconstruction.
How fuzzy matching catches names that resemble a sanctions-list entry without being spelled identically — handling transliteration, spelling variants, missing words, and word order — and why that reach is bought at the price of innocent lookalikes.
A name similarity only opens a question. Dates of birth, nationalities, and document numbers are the evidence that closes it, strengthening a genuine hit or supporting the release of an innocent namesake, always on the record.
Transaction screening reads the whole payment message, including debtor, creditor, their agents, and free-text remittance, at a point where the payment can still be stopped. A hit parks the payment in a hold queue for a reviewer to decide.
A screening platform connects list management, a matching engine, hold queues, and case-management tools inside the payment path. Its design answers hard questions about latency and availability, because a filter that silently stops checking is the dangerous failure.
A screening alert flags a payment or customer whose name or identifiers resemble a sanctions-list entry. This article explains how an analyst weighs evidence to clear a false positive or escalate a likely match, and why each decision is recorded.
Screening governance is the framework of policies, roles, approvals, and controls around a sanctions programme. This article explains how ownership and documented decisions let an institution defend its configuration choices to auditors and supervisors.
A screening system must catch true sanctions matches without burying analysts in false alerts. This article explains how synthetic test cases and careful threshold tuning balance those aims, and why each change is documented and re-tested.
Politically exposed persons hold prominent public roles that carry higher corruption risk. Screening flags them so a bank applies enhanced due diligence — a deeper, documented review and senior sign-off — rather than the hard payment stop a sanctions match triggers.
Adverse media screening checks a customer against negative news linking them to crime or misconduct. It surfaces risk that official lists miss and feeds due diligence rather than blocking payments — while generating false positives a programme must control.
Anti-money-laundering transaction monitoring reviews many transactions over time for patterns that suggest financial crime, after they settle rather than in the payment path. Alerts that survive investigation become suspicious activity reports filed with the authorities.
Payment fraud typologies are recognised patterns of attack — authorized push payment fraud, account takeover, and money-mule networks. Knowing each pattern's signals helps a bank detect and prevent it and protect the customer, and stays firmly on the defensive side.
Know your customer (KYC) identity checks and customer due diligence (CDD) establish who a customer is, who owns them, and how much risk they carry, before an account opens and throughout the relationship, with screening as one input.
When staff or systems spot activity that may indicate financial crime, firms escalate it internally and, where suspicion holds, file a suspicious activity report (SAR) or suspicious transaction report (STR) with the authorities, preserving the decision trail throughout.
A customer risk rating scores each relationship from factors such as geography, product, channel, and behaviour, and that score decides whether the customer receives standard or enhanced due diligence (EDD) and how often the file is reviewed.
Push and pull payments differ by which party starts the transfer. A push is initiated by the payer, a pull is collected by the payee under prior authority, with credit transfers and direct debits as the standard examples.
Compares a same-country payment with one that crosses a border, showing how differing currencies, correspondent banks, longer timelines, higher cost, and additional compliance checks turn a single hop into a multi-party chain.
Explains the four parties in a typical payment — payer, payer's bank, payee's bank, and payee — and how a scheme or network in the middle connects the two banks so each joins once and can reach all the others.
Explains how standing orders and scheduled credit transfers repeat a fixed payment on the payer's instruction, who controls them, and why they differ from a direct debit, where the payee collects and can vary the amount.
The annual Standards Release is SWIFT's yearly update to its message standards. It keeps formats aligned with new business needs, regulation, and corrections, following a fixed announce-to-go-live cycle that ends on a November weekend.
SWIFT gpi (global payments innovation) is a set of standards that made cross-border correspondent payments faster and more transparent, adding fee visibility and end-to-end tracking through a unique reference and a central Tracker.
Correspondent banking lets one bank access another's market by holding an account with it. Establishing a relationship means exchanging authorisations, performing due diligence, and opening accounts; withdrawing from relationships, known as de-risking, can cut off access to payments.
When a payment must be questioned, cancelled, or corrected, banks use dedicated exception messages: free-format MT n99 notes, MT n92 cancellation requests, and the ISO 20022 camt.056 and camt.029 pair, supported by SWIFT gpi stop-and-recall.
How cross-border payments route through correspondent banks in ISO 20022: a single pacs.008 passed bank to bank along the chain, versus a pacs.008 sent directly plus a pacs.009 COV cover message that repeats the customer details so every bank can screen the real parties.
How a customer or corporate instructs one or many credit transfers with a pain.001 message: what it carries, from the debtor and creditors to amounts and a requested execution date, and how the pain.002 status report replies.
What the ISO 20022 Business Application Header is: a standard envelope, the head.001 message, that carries the sender, receiver, message type, and a unique business message identifier, kept separate from the message body it accompanies.
The difference between structured and unstructured remittance information in a payment: why structured references such as invoice numbers improve automatic reconciliation, and what detail can be truncated when a message is translated to a legacy MT format.
ISO 20022 payments are moving postal addresses out of free-text lines into labelled fields for street, town, and country. A hybrid address keeps a structured town and country while allowing some detail on address lines during the transition.
Purpose codes and category-purpose codes are standard ISO 20022 external code lists that state why a payment is being made. They can influence routing, regulatory reporting, and screening, but a code is self-declared context, not proof.
High-value payment systems are usually central-bank real-time gross settlement systems that settle large payments individually and with finality. The HVPS+ (High Value Payments Plus) guidelines align how ISO 20022 messages are used across them, so a payment reads the same across borders.
A BIC (Business Identifier Code) identifies a financial institution so a payment can be routed to it, while an LEI (Legal Entity Identifier) identifies a legal entity for transparency. The two are structured differently and complement each other in modern payments.
A tour of the interbank systems that clear and settle payments — TARGET2 and EURO1 in Europe, Fedwire, CHIPS and FedNow in the United States, and CHAPS in the United Kingdom — and how real-time gross settlement differs from net settlement.
Settlement risk is the danger that one side of a trade completes while the other fails. In foreign exchange this is Herstatt, or principal, risk — reduced by settlement finality, payment-versus-payment, and the CLS system.
Real-time gross settlement systems settle payments one by one, yet still economise on cash. Central queues, bilateral and multilateral offsetting, and liquidity-saving mechanisms let banks settle more payments with less intraday liquidity and break gridlock.
The SEPA (Single Euro Payments Area) Direct Debit Business-to-Business scheme differs from the Core scheme: no no-questions refund right for authorised collections, a mandatory mandate check by the debtor's bank, and eligibility limited to non-consumer payers.
Confirmation of Payee is the United Kingdom's pre-payment name-checking service. Before a sterling transfer is sent, it tells the payer whether the name they typed matches the account holder, returning a match, close match, or no match, and it compares closely with the euro area's Verification of Payee.
The travel rule, based on Financial Action Task Force Recommendation 16, requires specified originator and beneficiary information to travel with a transfer through the payment chain, so that every institution can screen it, monitor it, and trace the funds if asked.
Payment transparency means complete, unaltered originator and beneficiary information must accompany a payment so every institution can screen it. Wire stripping — removing or altering that party data — defeats screening, and transparency controls exist to detect and prevent it.
Section 314(a) of the USA PATRIOT Act lets authorities ask financial institutions to search their records for named subjects of money-laundering or terrorism investigations. Firms search, report matches confidentially, and — unlike sanctions screening — freeze nothing.
Open banking lets licensed third parties access bank accounts, with the account holder's consent, through standard interfaces. This article explains PSD2, payment initiation and account information services, and the security rules that govern them.
Many countries now run payment systems that move money between accounts in seconds, at any hour, with final settlement. This article compares the major instant schemes and explains what they share and how they differ.
Proxy addressing lets a payer send money using a phone number, email, or identifier instead of a full account number, with a central directory resolving it. This article explains the mechanism, its benefits, and its risks.
Payments are governed by several kinds of body: central banks that operate and oversee systems, scheme owners that set rules, and conduct and competition regulators. This article explains who does what and why oversight matters.
A consolidated view of undoing a payment: rejects before settlement, returns and reversals after it, and recall requests that ask the receiving side to send funds back. Each has a different trigger, message, and outcome.
How bulk payments group many instructions into one file or message, using a group header and transaction counts, and how banks validate, split, and process those batches through a payment operations day.
How cheques and other paper instruments work, how modern image-based clearing settles them, why they persist in some markets, and how they compare with electronic transfers.
What Request to Pay is as a messaging layer that lets a payee ask a payer to pay while the payer stays in control, and how e-mandates digitise direct-debit authorisations over existing rails.
A central bank digital currency is a digital form of central-bank money. This article explains wholesale and retail designs, why central banks study them, and how they sit alongside commercial-bank money and existing payment rails.
Stablecoins are tokens intended to hold a stable value against a currency. This article explains how distributed-ledger rails move value, where these tokens touch regulated payments, and the risks that come with them.
Money crosses borders through more than the correspondent-banking chain. This article explains closed-loop networks, payment aggregators, card-scheme cross-border rails, and the quote-then-pay API model many modern networks use.
How a SWIFT MT message is checked before and during sending: mandatory versus optional fields, tags and formats, the network's own cross-field rules, and what a rejection means.
The three SWIFT messaging services — FIN for store-and-forward MT messaging, InterAct for real-time ISO 20022 exchanges, and FileAct for secure bulk file transfer — and when banks use each.
Bank-to-bank funds transfers on SWIFT — the MT202 and MT205 and their ISO 20022 successor pacs.009 — used for cover payments, own-account moves, and market settlement, and how they differ from customer transfers.
The SWIFT Customer Security Programme: mandatory and advisory controls that connected institutions implement and attest to each year, why it exists, and how attestations inform counterparty risk.
The Fedwire Funds Service is the Federal Reserve's real-time gross settlement system for high-value US dollar payments, settling each transfer individually and with finality in central-bank money.
CHIPS is a privately operated US high-value payment system that continuously matches and releases payments against running net positions during the day, then settles net balances at day's end over Fedwire.
TIPS is a Eurosystem service that settles instant payments individually, in central-bank money, around the clock, underpinning pan-European instant credit transfers and reducing settlement risk.
SIC is Switzerland's real-time gross settlement system for Swiss francs, operated by SIX for the Swiss National Bank with a cover check before settlement; euroSIC handles euro payments and is being discontinued at the end of 2027.
A comparison of the main interbank settlement models — real-time gross settlement, deferred multilateral netting, and instant retail settlement — across speed, liquidity use, finality, and settlement risk.
Why final settlement of interbank payments takes place in central-bank money, how direct and indirect participants are tiered, who may hold a settlement account, and why central-bank money is treated as the safest settlement asset.
How modern application programming interface based cross-border networks use a quote-then-pay model — locking an exchange rate for a short window, then submitting a payment order against that quote and tracking payout status through callbacks, illustrated with Thunes.
How a card-scheme cross-border service exposes a request and response API — payment requests with pre-agreed or one-shot quotes, balance requests, retrievable payment responses, and requests for information — illustrated conceptually with Mastercard Cross-Border Services.
Money laundering moves criminal proceeds through three classic stages so the funds appear lawful. This article explains placement, layering, and integration, and how terrorist financing differs, so controls can detect each stage.
The Financial Action Task Force sets the global standard against money laundering and terrorist financing. This article explains its 40 Recommendations, mutual evaluations, and the grey and black lists and what listing means for a country and its banks.
Sanctions evasion is attempted through front companies, transhipment, dual-use goods, ownership webs, and obscured party data. This defensive article describes the red flags and detection methods that let controls surface these patterns for review.
Transaction monitoring watches for named laundering behaviours such as structuring, pass-through movement, round-tripping, and layering. This defensive article explains each pattern and how scenarios and thresholds surface it for review.
Correspondent banking lets one bank move money through another's accounts to reach places it cannot serve directly. That reliance on a customer's customers raises financial-crime risk, so it is managed through structured due diligence.
Business email compromise and mandate fraud trick a payer into sending money to a criminal's account by impersonating a supplier or executive. Verification, call-backs, and Confirmation of Payee are the controls that catch them.
A beneficial owner is the real person who ultimately owns or controls a company. Identifying the ultimate beneficial owner lets sanctions and money-laundering controls see past the company name to the human behind it.
A payment hub is the central engine a bank uses to receive, standardise, validate, enrich, and route payments. This article describes the capabilities that leading hub products share, without naming any single vendor.
A template is a reusable starting point that fixes a payment's message type and format and pre-fills standing fields. This article explains how templates help operators capture payments quickly and consistently.
Reference and standing data are the lookup tables a payment hub relies on to validate, enrich, and route payments. This article explains what they contain, how they are kept current, and why stale data causes repairs and delays.
A screening product manages several distinct kinds of list — official sanctions, politically exposed persons, adverse media, internal watchlists, allow lists, geography, institution, and regulatory-request lists. Each list has a different purpose and drives matching and disposition differently.
An end-to-end view of the capabilities leading sanctions screening products share — list management, a matching engine, real-time and batch screening, hold queues, alert and case management, disposition, tuning, and audit.
An end-to-end view of how fraud detection products work — real-time scoring, rules engines combined with machine-learning models, behavioural, device, and consortium signals, case management, and feedback loops that retrain the models.
SWIFTNet is the secure private network that carries every Swift service. This article explains how institutions connect to it and maps the four messaging services that ride on top.
The Alliance product family is how institutions actually send and receive Swift messages. This article explains the on-premises and cloud interfaces, the connectivity components, and how a firm chooses between them.
FINplus is the SWIFTNet service that carries ISO 20022 messages for cross-border payments and securities, alongside legacy FIN. This article explains FINplus, the interactive Browse service, and FileAct's two delivery modes.
SWIFTRef is Swift's reference-data utility, publishing authoritative directories of institutions, codes, and settlement details so payment systems can validate and route correctly. Its accuracy reduces repairs and delays before a message is sent.
The BIC Directory is the authoritative list of Business Identifier Codes, while Bank Directory Plus adds national clearing codes, hierarchy, and legal-entity data. Payment operations use both to route and validate cross-border transfers.
IBAN Plus derives the correct BIC from an account number, the SSI Directory records where and how to settle, the SEPA routing directory shows reachability, and RMA Plus governs granular messaging authorisations.
The gpi (global payments innovation) service family applies end-to-end tracking and service-level rules to cross-border payments, with distinct variants for customer transfers, cover payments, financial-institution transfers, and links to domestic instant rails.
Payment pre-validation checks beneficiary account details and other data before a cross-border payment is sent, so errors are caught at the start rather than becoming costly repairs and delays later in the chain.
SWIFT Go is a service for fast, predictable low-value cross-border payments for consumers and small businesses, using pre-agreed terms on speed, fees, and data quality built on tighter rules than a standard transfer.
The Transaction Manager is a central platform that orchestrates a payment as one shared transaction in ISO 20022, preserving data across parties and reducing truncation as part of the shift from point-to-point messaging to a central platform.
Swift offers a set of hosted compliance services, including sanctions and name screening, transaction screening, and analytics, letting smaller institutions run these controls through a shared utility rather than building everything in-house.
The Payment Controls Service is an in-network control that screens outgoing payment messages against configurable limits and rules, flagging or holding unusual instructions so fraud and errors can be caught before a message leaves the institution.
The KYC Registry is a shared platform where banks contribute and consume standardised due-diligence data and documents, so correspondent know-your-customer information is collected once and reused instead of exchanged bilaterally many times over.
Swift MT (Message Type) messages are grouped into numbered categories by business area, from customer payments to securities and cash management, so each message carries a predictable purpose and structure across the network.
Category 7 Swift messages carry documentary credits and guarantees between banks in trade finance, supporting importers and exporters, while the Bank Payment Obligation offers an irrevocable interbank undertaking as an alternative structure.
Beyond payments, Swift carries category 3 treasury confirmations, category 5 securities settlement and reconciliation, and category 6 commodities messages, letting post-trade confirmation and settlement instructions travel over one network.
Corporates connect to Swift through models such as SCORE and MA-CUG, exchanging payment instructions and statements with their banks over a single channel instead of maintaining many separate proprietary connections.
The US Automated Clearing House (ACH) moves high-volume, low-value credit and debit transfers in batches and settles net positions across banks' Federal Reserve accounts.
The RTP network from The Clearing House is a US instant-payment rail that runs around the clock, uses ISO 20022 messages, and settles with immediate finality against a prefunded account at the Federal Reserve.
Lynx is Canada's high-value real-time gross settlement system, operated by Payments Canada and settling in Bank of Canada money, with mechanisms that balance immediate finality against efficient use of liquidity.
CIPS clears and settles cross-border and offshore renminbi payments, while CDFCPS refers to China's domestic clearing arrangements; the two serve different participants and purposes.
The Clearing House Automated Transfer System (CHATS) is Hong Kong's high-value settlement system, unusual for running real-time settlement in four currencies side by side.
India's Immediate Payment Service moves money between banks instantly around the clock, and the Unified Payments Interface layers a simple addressing and app model on top of those rails.
Australia's New Payments Platform clears instant payments in a distributed way — banks exchange messages directly and each payment settles individually in central-bank money.
T2 is the Eurosystem's high-value settlement system that replaced TARGET2 in 2023, splitting central-bank operations and high-value payments across separate accounts behind one shared gateway.
TARGET2-Securities settles the securities and cash legs of a trade together in central-bank money, applying delivery-versus-payment — the securities analogue of payment-versus-payment.
A short map of payment message families that sit outside the SWIFT world: card-transaction messaging with International Organization for Standardization (ISO) 8583, the trade-oriented UN/EDIFACT, North American ANSI ASC X12, and the United Kingdom's Bacs Standard 18 file layout.
SWIFT Financial Application (FIN) Category 1 covers customer payments, where a customer is a party to the transfer. This guide walks the MT101, MT102, MT103, and MT104 messages along two axes: single versus multiple, and push versus pull.
SWIFT Financial Application (FIN) Category 2 covers transfers where banks are the parties. This guide separates own-account from third-party transfers, single from multiple, and explains the notice nature of MT210 and the MT202 COV cover message.
SWIFT Category 0 system messages pass between a user and the network itself, not between banks. This guide covers acknowledgements, authentication responses, retrieval and delivery notifications, and why a valid payment can still fail at the network layer.
When a SWIFT MT payment goes wrong, banks use a small family of exception messages — MTn92, n95, n96, and n99 — to ask for cancellation, query, answer, and explain. ISO 20022 replaces this toolkit with camt.056, camt.029, and pacs.004.
Common Global Implementation – Market Practice (CGI-MP) is a multi-bank forum that agrees a shared way to use ISO 20022 for corporate-to-bank messages, so a company can build one payment profile instead of a different variant for every bank.
Universal Confirmation asks every bank to confirm the fate of a payment — credited, returned, or rejected — feeding the gpi tracker. This piece walks through the gpi service variants and the Daily Validation Report as a detective control.
The anti-money-laundering world runs on a layered set of institutions: a global standard-setter, regional assessment bodies, a network of financial-intelligence units, and an industry group. Knowing who does what makes the rules easier to read.
Trade-based money laundering moves illicit value through the buying and selling of goods rather than obvious cash. Because the value hides in invoices and shipments, controls have to look beyond the payment itself.
Anti-money-laundering reporting runs on two complementary tracks: objective threshold reports for large cash, and judgement-based suspicious-activity reports. Together they give the authorities both a wide net and a sharp filter.
FATCA and the Common Reporting Standard make financial institutions report account information to tax authorities. They share plumbing with anti-money-laundering checks but answer to a separate set of duties.
Anti-money-laundering duties reach well beyond banks, into professions and sectors from law and real estate to casinos and charities. A risk-based approach spreads those duties and asks each firm to assess and document its own exposure.
A book payment moves money between two accounts held at the same bank, settled on that bank's own ledger. When the payer and payee are both customers of one bank, the payment is on-us: fast, cheap, and with no interbank settlement to arrange.
Payment systems carry credit, liquidity, settlement, operational, systemic, and legal risk. This guide names each risk plainly and explains the main mitigations, from settlement in central-bank money to payment-versus-payment and netting with finality.
Payment institutions, e-money institutions, money transfer operators, and open-banking providers all move money without being banks. This guide explains what each does, how they reach clearing, and why they carry the same anti-money-laundering duties as banks.
The Federal Reserve's FedNow Service settles each retail payment individually and irrevocably in central-bank money, around the clock, so the receiver can use the money in seconds — a real-time gross settlement rail that contrasts with batch, deferred-net ACH.
Beyond the instant UPI and IMPS rails, India runs RTGS for high-value gross settlement in the books of the Reserve Bank of India, NEFT for half-hourly net batches, and NACH for bulk recurring collections and disbursements.
Singapore settles high-value payments gross in MAS's MEPS+, clears near-instant retail transfers through FAST with deferred-net settlement in MEPS+, and lets people address those FAST payments by a simple PayNow proxy instead of an account number.
Japan settles large-value yen payments gross in the Bank of Japan's BOJ-NET, while the Zengin System clears domestic retail credit transfers and settles their net positions across accounts at the Bank of Japan — with large items diverted to BOJ-NET.
Brazil's Pix settles instant retail payments individually over the central bank's SPI, addressed by a simple Pix key, while the STR moves high-value interbank obligations gross in central-bank reserves — the retail-instant and wholesale-RTGS halves of the Banco Central do Brasil's system.
Banco de Mexico's SPEI processes payment orders individually and settles them in central-bank money within seconds, addressed by an 18-digit CLABE — a real-time gross settlement system that queues rather than overdraws when a bank is short of liquidity.
PAPSS lets a company pay for intra-African trade in its own local currency while the beneficiary receives theirs, routing the instruction through the two central banks and netting the day's cross-currency balances among them — reducing reliance on a hard-currency intermediary.
Buna, founded by the Arab Monetary Fund, settles cross-border payments across multiple regional and international currencies in central-bank money, with sanctions and financial-crime screening applied both before and after settlement — a multi-currency real-time gross settlement service for the Arab region and beyond.
STEP2 is EBA CLEARING's pan-European automated clearing house: it validates and clears standard SEPA credit transfers in cycles, calculates each participant's net position, and settles those positions in central-bank money in TARGET2 — the clearing layer beneath a non-instant SCT.