GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
PAYMENTSSIGNAL

The interactive academy for the standards, messages, and rails that move money.

GET IN TOUCH
LEARNING PATH / 14 STOPS

Payments business analyst

This path builds the breadth a business analyst needs: how a payment actually works, who the parties are, and how clearing and settlement differ. It then adds the flows you will most often write requirements against — the SEPA credit transfer lifecycle, its exception flows, correspondent routing choices, and the interbank message family used across modern rails. The goal is enough depth to ask precise questions, not to configure systems yourself.

FOR: Business analysts who gather requirements, write user stories, and translate between product, operations, and engineering teams on payment projects.

AFTER THIS PATH YOU CAN

  • You can walk a payment from initiation to settlement and name every party and account touched along the way.
  • You can explain the difference between clearing and settlement and why it changes how requirements are written.
  • You can describe the SEPA credit transfer happy path and its reject, return, and recall exception flows.
  • You can read a requirement involving serial or cover routing and know which banks and messages are involved.
  • You can identify which pacs message carries a given interbank event and ask the right questions about its fields.

THE LINE

Learning path as a transit lineEach station is a stop on the path; filled stations are mastered, the ringed station is where you are, and the rest are ahead. The full list follows this map as text.
  1. 01GO TO L2 — PRACTITIONER VIEW
    What a payment actually isNo coins move when you pay — ledger entries change. What a payment really is, who asks for it, and what must happen before anyone is paid.Every requirement you write rests on a shared definition of what a payment is. Getting the basic model right prevents entire categories of misunderstanding with stakeholders.
  2. 02GO TO L3 — TECHNICAL DETAILS
    The parties in a paymentDebtor, creditor, and their agents: the standard names for everyone in a payment, and why precise role names prevent expensive confusion.User stories in payments name parties: debtor, creditor, and their agents. Using these roles precisely is the single fastest way to make your requirements unambiguous.
  3. 03GO TO L3 — TECHNICAL DETAILS
    The payment lifecycleFrom capture to confirmation: the stages every payment passes through, and where clearing and settlement fit in the journey.Most requirements attach to a specific lifecycle stage — capture, validation, execution, or confirmation. Knowing the stages lets you place a change request where it actually belongs.
  4. 04GO TO L2 — PRACTITIONER VIEW
    Instruments, rails, and schemesPush or pull, card or transfer — and the rails and schemes underneath. How to tell the payment type from the infrastructure that carries it.Product conversations jump between instruments, rails, and schemes, and the words are often used loosely. You need the distinctions to scope a feature to the right rail.
  5. 05GO TO L3 — TECHNICAL DETAILS
    Clearing versus settlementClearing works out who owes what; settlement actually pays it. Two words that sound alike and describe completely different risks.Whether funds have cleared or settled changes what a status means and what a customer can be told. Requirements that confuse the two produce systems that mislead users.
  6. 06GO TO L2 — PRACTITIONER VIEW
    Correspondent banking, nostro & vostroHow banks pay across borders with no shared system: accounts held at each other, chains of correspondents, and what nostro and vostro mean.Cross-border requirements usually involve nostro and vostro accounts even when nobody says so out loud. A working model of correspondent banking helps you spot hidden assumptions.
  7. 07GO TO L2 — PRACTITIONER VIEW · OPTIONAL
    Charges and foreign exchangeWho pays the fees, and whose exchange rate applies? Why the amount received on a cross-border payment is not always the amount sent.Charge-bearer options and foreign-exchange handling generate a surprising share of customer complaints and requirement disputes. Useful background when your project touches pricing or cross-border flows.
  8. 08GO TO L2 — PRACTITIONER VIEW
    SEPA: one euro payments areaWhat the Single Euro Payments Area is, who writes its scheme rulebooks, and why a euro payment works the same way from Lisbon to Helsinki.If you work on euro payments, SEPA is the frame everything else sits inside. Knowing the scheme landscape tells you which rulebook a requirement ultimately traces back to.
  9. 09GO TO L3 — TECHNICAL DETAILS
    The SCT lifecycleHow one SEPA credit transfer travels from the debtor's instruction through clearing and settlement to the creditor's account — and what each hop does.The SEPA credit transfer is the workhorse flow you will document most often. Knowing the four-corner model and message sequence lets you write acceptance criteria that match reality.
  10. 10GO TO L3 — TECHNICAL DETAILS
    R-transactions: reject, return, recallWhen an SCT does not go to plan: rejects before settlement, returns after it, and recalls where the sender's bank asks — and may be refused.Exception paths are where analysts earn their keep: rejects, returns, and recalls each have different triggers, messages, and outcomes. Requirements that only cover the happy path fail in production.
  11. 11GO TO L2 — PRACTITIONER VIEW
    Serial versus cover routingTwo ways to route the same payment: pass the MT103 bank to bank, or send it direct and move the money separately with an MT202 COV.When a cross-border project mentions serial or cover payments, the routing choice changes which banks see the payment detail and when funds move. You need the concept even if you never build the messages yourself.
  12. 12GO TO L3 — TECHNICAL DETAILS
    The pacs family: interbank messagesThe interbank workhorses: pacs.008 and pacs.009 move value, pacs.002 reports status, and pacs.004 brings money back.Interbank requirements increasingly reference pacs messages directly. Knowing which message carries a credit transfer, a status report, or a return lets you review interface specs with confidence.
  13. 13GO TO L2 — PRACTITIONER VIEW
    Open banking, PSD2, and payment APIsHow customers let regulated third parties see their accounts or start payments through consented, authenticated bank APIs instead of screen-scraping.Open banking and PSD2 reshaped who can initiate a payment and see account data. A business analyst is expected to understand APIs, consent, and strong customer authentication when scoping modern payment products.
  14. 14GO TO L2 — PRACTITIONER VIEW
    Cross-border payment networks beyond correspondent bankingWhy sending money across borders is slow and opaque through correspondent chains, and how closed-loop networks and quote-then-pay APIs offer another route.Correspondent banking is no longer the only way across a border. Knowing how closed-loop networks and quote-then-pay APIs work lets you compare build-or-partner options for cross-border flows.