Know the answer. Explain the payment.
Genuine questions a payments interviewer can reasonably ask, from foundations to senior-level exceptions. Every answer starts directly, adds operational context, and links back to the teaching or official evidence that supports it.
Interview-worthy coverage, without filler.
The bank is explicitly curated by domain. New site content does not become a question automatically: it must test a concrete concept, decision, lifecycle, control, or troubleshooting skill and pass the editorial quality checks.
Build your interview set.
14 matches
Showing 1–14 · Page 1 of 1
Payment architecture & BA delivery
Payments foundations
TRICKYClearing vs settlementCompare Clearing and Settlement on “What it is”.
MODEL ANSWERDIRECT ANSWER
Clearing: The exchange, validation, matching, and often netting of payment instructions between institutions.
WHY IT MATTERS
Settlement: The discharge of the resulting obligations — money actually moving between the institutions' accounts.
TRICKYMX vs MT corporate payment lifecycleCompare ISO 20022 / CBPR+ lifecycle and Legacy MT and transition lifecycle on “Corporate instruction”.
MODEL ANSWERDIRECT ANSWER
ISO 20022 / CBPR+ lifecycle: pain.001 carries a structured customer credit-transfer initiation.
WHY IT MATTERS
Legacy MT and transition lifecycle: MT101 requests one or more transfers, including relay use cases. The business intent aligns, but grouping, structure, and channel rules differ.
TRICKYOUR vs SHA vs BENCompare OUR and SHA on “Who pays which charges”.
MODEL ANSWERDIRECT ANSWER
OUR: The originator pays all charges — their own bank's, the intermediaries', and the beneficiary bank's.
WHY IT MATTERS
SHA: The originator pays their own bank's charges; the beneficiary bears the charges on the receiving side, and intermediary deductions typically fall on the beneficiary side too. Under BEN, the beneficiary bears all charges, including the sending bank's — usually taken out of the payment amount itself.
SWIFT & MT
TRICKYMT103 vs pacs.008Compare MT103 and pacs.008 on “Standard and syntax”.
MODEL ANSWERDIRECT ANSWER
MT103: Swift MT: a proprietary block-and-tag text format (blocks 1-5, fields like 20, 32A, 50a, 59a) maintained through Swift's annual standards releases. pacs.008: ISO 20022: an open standard with an XML syntax generated from a formal data model; pacs.008 is the FI-to-FI customer credit transfer in the pacs family.
TRICKYMT202 COV vs pacs.009 COVCompare MT202 COV and pacs.009 COV on “Message standard”.
MODEL ANSWERDIRECT ANSWER
MT202 COV: A legacy SWIFT MT (message type) in the FIN format: fixed field tags, a 4-character message type, and character-set limits inherited from the network. pacs.009 COV: An ISO 20022 (MX) message in structured XML: named elements, richer data types, and a Business Application Header carrying routing and identity metadata. Both are financial-institution transfers used specifically to cover an underlying customer credit transfer.
TRICKYSerial vs cover routingCompare Serial routing and Cover routing on “Messages involved”.
MODEL ANSWERDIRECT ANSWER
Serial routing: One customer credit transfer (MT103, or pacs.008 in ISO 20022) travels the whole route, relayed by each bank in the chain.
WHY IT MATTERS
Cover routing: Two message streams: the customer credit transfer goes straight to the beneficiary's bank, and a separate bank-to-bank cover payment (MT202 COV, or pacs.009 COV) moves the funds through the correspondents. The COV variant exists specifically so that the cover leg repeats the underlying originator and beneficiary details instead of hiding them.
Clearing & settlement
TRICKYRTGS vs deferred net settlementCompare RTGS and Deferred net settlement on “Settlement unit”.
MODEL ANSWERDIRECT ANSWER
RTGS: Each payment settles individually, at its gross (full) amount.
WHY IT MATTERS
Deferred net settlement: Many payments are accumulated and offset; only each participant's net position settles.
MEDIUMRTGS vs deferred net settlementWhat is the essential difference between RTGS and Deferred net settlement?
MODEL ANSWERDIRECT ANSWER
Real-time gross settlement settles every payment individually and immediately; deferred net settlement accumulates payments and settles only the net positions at designated times.
WHY IT MATTERS
The trade is liquidity cost against credit risk. Reach for RTGS when the amounts are large enough, or the payments urgent enough, that credit exposure between banks is unacceptable — you are paying liquidity to eliminate risk. Reach for deferred net settlement when volumes are high and values are small, and the netting benefit outweighs the managed inter-cycle exposure. Modern practice mixes the models: bulk retail on DNS, high-value on RTGS, and instant rails borrowing the gross-and-final idea with prefunded liquidity.
ISO 20022 & CBPR+
TRICKYUnstructured / hybrid vs fully structured addressCompare Unstructured / hybrid address and Fully structured address on “How the data is held”.
MODEL ANSWERDIRECT ANSWER
Unstructured / hybrid address: Unstructured: the whole address sits in a few free-text lines with no labelled parts.
WHY IT MATTERS
Hybrid: town and country are labelled elements, but street and building stay as free text. Fully structured address: Every component — street name, building number, town name, post code, country — is carried in its own named element.
Operations & architecture
EASYReconciliationWhat does “Reconciliation” mean in payments?
MODEL ANSWERDIRECT ANSWER
Reconciliation is the control that compares two independent records of the same activity and explains every difference between them.
WHY IT MATTERS
In payments the classic example is nostro reconciliation: a bank matches the entries it expects on its account at a correspondent against the statement the correspondent actually sends, such as an MT940. Items that do not match — a missing credit, an unexpected debit, a duplicated entry — become breaks that someone must investigate and clear. How often reconciliation runs, and how much of it is automated, varies widely between institutions.
EASYStraight-through processingWhat does “Straight-through processing” mean in payments?
MODEL ANSWERDIRECT ANSWER
Straight-through processing means a payment travels from initiation to posting with no human touching it: validation, enrichment, routing, screening, and accounting all happen automatically.
WHY IT MATTERS
The share of payments that achieve this — the STP rate — is a standard operations metric, because every payment that falls out of the automatic flow lands in a repair or investigation queue and costs disproportionate money and time. STP rates are mostly determined upstream: clean reference data, correct identifiers, and structured message formats prevent the fallout that manual teams otherwise absorb. Much of the case for ISO 20022's richer structure is ultimately an STP argument.
MEDIUMPayment controlsWhat does the four-eyes or maker-checker control achieve in payment processing?
MODEL ANSWERDIRECT ANSWER
It requires one person to create or repair a payment and a different authorized person to approve its release.
WHY IT MATTERS
The control separates duties, reduces the chance that one mistake or compromised credential can move value, and creates evidence of who prepared and approved the instruction.
COMMON MISTAKE
A second click by the same user or a purely technical validation is not independent maker-checker approval.
MEDIUMPayment enginesWhich checks should a payment engine perform before releasing a payment?
MODEL ANSWERDIRECT ANSWER
It should authenticate the instruction, validate mandatory data and account status, check funds and limits, apply routing and duplicate controls, call fraud and compliance checks, and confirm authorization before release.
WHY IT MATTERS
The exact sequence varies by product and rail. A strong design distinguishes hard validation failures, repairable data issues, compliance holds, and downstream technical failures so each outcome reaches the right queue and customer status.
EASYClient payment channelsThrough which channels can a bank receive customer payment instructions?
MODEL ANSWERDIRECT ANSWER
Common channels include online and mobile banking, branch or operations entry, host-to-host files, APIs, EBICS, SWIFT for Corporates and scheduled or bulk-payment services.
WHY IT MATTERS
Each channel has a different authentication, authorization, file or message format, cut-off, duplicate-control and acknowledgement model. The payment engine should normalize accepted instructions into a canonical form while preserving source identifiers and audit evidence.
