Banking Domain Knowledge Base

A comprehensive, engineer-focused reference for payment systems, ISO 20022 messaging, core banking concepts, and Australian payment infrastructure. Built for Java/Spring developers working in the payments domain.

What's in This Knowledge Base?

Section	Topics Covered
ISO 20022 Messages	pain.001, pain.002, pacs.008, pacs.002, camt.053, camt.054, camt.055/056, pain.007/pacs.007
Payment Flows	Inbound, Outbound, On-Us, Off-Us
Payment Rails	NPP, PayTo, SWIFT, BECS, Direct Debit, BPAY, RTGS/HVCS
Parties & Institutions	Debtor, Creditor, FIs, Correspondent Banks, Nostro/Vostro
Accounting & Posting	Debit/Credit Post, Debit Reversal, Payment Return
Clearing & Settlement	DNS, RTGS, ESA, Liquidity Management, Gridlock Resolution
Risk & Compliance	Fraud, CoP, Sanctions, AML/CTF, KYC, Regulatory Reporting
Operations	Reconciliation, Exceptions & Investigations, FX, Error Codes
Architecture	Payment Hub, Idempotency, FIS Integration
Modern Banking	Open Banking/CDR, ISO 20022 Migration, Account Types

Interactive End-to-End Payment Lifecycle Engine

The interactive engine below illustrates a complete outbound off-us NPP credit transfer — the most common domestic payment type in Australia.

End-to-End Payment Lifecycle Engine (10 Steps)

WORKFLOW STAGESSCENARIO: ✅ Happy Path (NPP Real-Time)

1. Payment Initiation

Debtor / Payer App • pain.001.001.11

⚡ PROCESSING

2. AuthN & AuthZ Checks

Debtor Bank Gateway • OAuth2 / FAPI

QUEUED

3. Available Balance Check

Core Banking Engine • Internal API

QUEUED

4. Compliance & Risk Screening

Sanctions & Fraud Engine • Internal Decision Engine

QUEUED

5. Debtor Account Posting

Debtor Bank Ledger • camt.054 (Debit)

QUEUED

6. Payment Rail Routing

Payment Hub Router • Scheme Dispatch

QUEUED

7. Interbank pacs.008 Message

NPP / SWIFT Network • pacs.008.001.10

QUEUED

8. Central Bank Settlement

RBA Fast Settlement Service • RITS / FSS RTGS

QUEUED

9. Creditor Account Posting

Creditor Bank Ledger • camt.054 (Credit)

QUEUED

10. Confirmation & pacs.002

Creditor Bank -> Debtor Bank • pacs.002.001.12

QUEUED

1. Payment Initiation

Payer enters payment details ($500 to BSB 062-000, Account 12345678) and submits instruction.

Key Engine Operations:

Customer authenticates via MFA (biometrics/OTP) in Mobile App or Corporate Treasury Portal.
API packages payment parameters into ISO 20022 pain.001 (Customer Credit Transfer Initiation).
System assigns an EndToEndId (E2E) for tracing through all downstream networks.

System Component

Debtor / Payer App

Protocol / Schema

pain.001.001.11

Banking Knowledge Path

Use this path as a guided entry point for learning banking and payments topics in a practical order.

How To Use This Path

Read each stage in order the first time.
Use the Role Tracks below after Stage 2 to specialize.
Keep payment_lifecycle_101 and the glossary open while reading message specs.

Stage 0 - Foundations (Beginner)

Start here if you are new to the banking/payments domain language.

Stage 1 - Core Payment Flows (Beginner -> Intermediate)

Learn the flow categories and routing decisions.

Stage 2 - ISO 20022 Message Chain (Intermediate)

Study messages in execution order:

pain.001 - customer payment initiation
pacs.008 - interbank credit transfer
pacs.002 - status report
camt.054 - debit/credit notification
camt.053 - account statement

Then exception messages: 6. pacs.004 - payment return 7. pain.007 and pacs.007 - reversal 8. camt.055 and camt.056 - cancellation/recall 9. pain.004 Clarification - common naming confusion

Stage 3 - Rails and Networks (Intermediate)

NPP
PayTo — Modern pull payments / NPP mandates
BECS Direct Entry — Batch credit/debit rail
Direct Debit / BECS DDR
BPAY
RTGS / HVCS / RITS — High-value settlement
SWIFT — Cross-border messaging
Correspondent Banking

Stage 4 - Ledger and Core Banking (Intermediate -> Advanced)

Stage 5 - Risk, Compliance, and Operations (Advanced)

Fraud Detection and Prevention
Confirmation of Payee (CoP)
Sanctions Screening
AML, CTF, and KYC
Regulatory Reporting — TTR, IFTI, SMR, APRA
Payment Exceptions and Investigations
Reconciliation
Error Codes Reference
Testing in Banking and Payments

Stage 6 - Architecture and Engineering Patterns (Advanced)

Stage 7 - Modernization and Strategy

Role Tracks

Developer Track

Follow: Stage 0 -> Stage 1 -> Stage 2 -> Stage 4 -> Stage 5 Focus topics:

Message schemas and field mapping
Idempotent posting and retries
Exception-safe state transitions

Operations / Analyst Track

Follow: Stage 0 -> Stage 1 -> Stage 3 -> Stage 5 Focus topics:

Status monitoring and exception handling
Reconciliation and return workflows
SLA and incident triage

Compliance / Risk Track

Follow: Stage 0 -> Stage 1 -> Stage 5 Focus topics:

Sanctions, AML/KYC, fraud controls
Hold/release/return decision points
Regulatory reporting and evidence

Product / Business Track

Follow: Stage 0 -> Stage 1 -> Stage 3 -> Stage 6 Focus topics:

Rail capability and customer experience trade-offs
Pricing/latency/risk considerations
Modernization opportunities

Quick Revision Path (60-90 minutes)

If you need a fast refresh before interviews or design discussions:

Payment Lifecycle 101
On-Us Transactions and Off-Us Transactions
pain.001 -> pacs.008 -> pacs.002
pacs.004, Debit Reversal, Payment Return
Reconciliation, Fraud, Sanctions

ISO 20022 Message Chain Reference

The standard execution chain for credit transfers involves:

pain.001: Customer Payment Initiation
pacs.008: Interbank Credit Transfer
pacs.002: Payment Status Report
camt.054: Bank-to-Customer Debit/Credit Notification
pacs.004: Payment Return (Exception Path)

For full interactive lifecycle simulation and message payload details, see the interactive engine at the top of this guide or Payment Lifecycle 101.

Key ID Fields — Traceability Across Messages

Every payment carries a chain of IDs that allow full end-to-end tracing:

ID	Who Sets It	Lives In	Purpose
`EndToEndId`	Originating customer	pain.001 → pacs.008 → camt.054	Customer's own reference; never changed
`InstrId`	Debtor bank	pacs.008, pacs.002	Bank's instruction reference
`TxId`	Debtor bank	pacs.008, pacs.002	Unique transaction ID for dedup
`MsgId`	Each sender	All messages	Message-level dedup
`UETR`	Debtor bank	SWIFT messages	Universal tracker for gpi
`AcctSvcrRef`	Creditor bank	camt.053, camt.054	Bank's ledger reference
`MndtId`	Creditor/payer	Direct debit messages	PayTo/BECS mandate reference

Payment Scheme Quick-Select

Is the payment a direct debit (pull)?
  └─► PayTo (NPP) for new — BECS DDR for legacy

Is the payment international?
  └─► SWIFT (MT103 / pacs.008)

Is the payment domestic?
  ├─ Same bank (both accounts at our institution)?
  │   └─► On-Us — internal book transfer, no external network
  │
  ├─ High-value or time-critical (> ~$250K)?
  │   └─► RTGS / HVCS
  │
  ├─ Bill payment with BPAY biller code?
  │   └─► BPAY
  │
  ├─ Creditor bank supports NPP?
  │   └─► NPP / Osko — real-time, 24/7
  │
  └─ Fallback
      └─► BECS Direct Entry — next business day

Risk & Compliance Checkpoints

Every payment — inbound or outbound — passes through these controls:

Checkpoint Order	Risk / Compliance Control	Target Identifiers & Payload	Failure Disposition & Impact
1. Duplicate Check	Idempotency Key & MsgId	`MsgId`, `TxId`, `EndToEndId` within 48h deduplication cache	Immediate rejection with `DUPL` error code.
2. Schema Validation	Structural & Semantic Check	ISO 20022 XSD syntax, valid BIC/BSB format, currency codes	Rejects with `NARR` or validation error response.
3. Authentication	Identity & Access Control	OAuth 2.0 mTLS cert, digital signatures, customer MFA token	HTTP 401/403 or signature mismatch rejection.
4. Sanctions Screening	Global Watchlist Match	OFAC, UN, DFAT, DFAT Consolidated list (Debtor/Creditor/BICs)	Immediate payment freeze; compliance referral.
5. Fraud Assessment	Behavioral & Velocity Analysis	Device fingerprint, IP geo-velocity, historical profile ML score	Step-up OTP challenge, delay, or fraud block.
6. AML / TM Check	Anti-Money Laundering Rules	Structuring detection (<$10K), mule heuristics, pass-through	Straight-Through Processing continues; analyst SMR case raised.
7. Balance / Limit Check	Financial Solvency (Outbound)	Available balance, customer daily limits, overdraft allowance	Rejection with `AM04` (Insufficient Funds).

Australian Regulatory Landscape

Body	Role	Key Obligations
RBA	Central bank, settlement operator	ESA management, RTGS, NPP FSS
APRA	Prudential regulator	ADI licence, capital (Basel III), LCR/NSFR
AUSTRAC	AML/CTF regulator	TTR, IFTI, SMR reporting
ASIC	Market conduct regulator	Financial services licensing
OAIC	Privacy regulator	CDR / Open Banking data rules
AusPayNet	Payment scheme operator	BECS, cheque rules
NPPA	NPP operator	NPP/Osko/PayTo scheme rules

Glossary of Common Terms

Term	Definition
ADI	Authorised Deposit-taking Institution — licensed bank/credit union
ESA	Exchange Settlement Account — account at RBA used for final settlement
BIC / SWIFT code	Bank Identifier Code — uniquely identifies a financial institution
BSB	Bank State Branch — 6-digit code identifying an AU bank branch
IBAN	International Bank Account Number — standardised account number
PayID	Proxy address (phone/email/ABN) mapped to a BSB/account via NPP
UETR	Unique End-to-end Transaction Reference — UUID used in SWIFT gpi
DNS	Deferred Net Settlement — obligations netted and settled at end of day
RTGS	Real-Time Gross Settlement — each payment settled individually, in real time
LCR	Liquidity Coverage Ratio — APRA regulatory liquidity metric
PEP	Politically Exposed Person — requires enhanced due diligence
SAR / SMR	Suspicious Activity/Matter Report — filed with AUSTRAC
TTR	Threshold Transaction Report — cash transactions ≥ AUD 10,000
IFTI	International Funds Transfer Instruction — all cross-border transfers
ChrgBr	Charge Bearer — who pays bank fees (DEBT/CRED/SHAR/SLEV)
Nostro	"Our" account held at another bank
Vostro	"Your" (another bank's) account held at our bank
Straight-Through Processing (STP)	Payment processed end-to-end without manual intervention
CoP	Confirmation of Payee — verifying payee name matches account before payment

Java / Spring Stack Reference

Typical technology choices for a payment processing system:

Layer	Technologies
API	Spring Boot, Spring Web MVC / WebFlux
Messaging	Spring Integration, Apache Kafka, IBM MQ, RabbitMQ
ISO 20022 Parsing	JAXB, prowide-core, open-banking-java-sdk
Database	PostgreSQL / Oracle (transactional), Redis (caching)
Security	Spring Security, HSM for key management
Scheduler	Spring Batch (batch payments), Quartz
Observability	Micrometer, Prometheus, Grafana, ELK Stack
Testing	JUnit 5, Mockito, Testcontainers, WireMock

Contributing & Structure

Each page in this knowledge base follows a consistent structure:

Overview — What it is and why it matters
Key concepts — Definitions, types, tables
Flow diagrams — ASCII art showing the process
Field/code references — Lookup tables
Java/Spring notes — Practical implementation snippets
Related concepts — Cross-links to related pages

Interview Questions

How do you explain banking payment architecture end-to-end to new backend engineers?
What boundaries should be explicit between payment orchestration and core banking systems?
Which controls are non-negotiable before allowing straight-through processing?
How would you measure payment platform maturity beyond transaction throughput?

Short answer guide:

Teach by lifecycle: initiation, screening, clearing, settlement, notification.
Keep orchestration stateless and ledger authority centralized.
Enforce sanctions/fraud/AML gates with strong observability.
Track failure recovery, exception handling quality, and reconciliation accuracy.

Interview Focus

Explain payment systems as lifecycle stages with explicit control, audit, and recovery boundaries.

Interview Trap

Discussing rails without distinguishing clearing from settlement and ledger finality.