GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
INTERVIEW DESK / 386 CURATED Q&AS

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.

Shubham Mathure, Senior Business Analyst and Payments SME
CREATED & CURATED BY

Shubham Mathure

Senior Business Analyst SME in payments technology, with expertise in SWIFT, ISO 20022, payment operations, and financial messaging. Creator of Payments Signal—making complex payment infrastructure clear and practical for everyone.

9+ yearsPAYMENTS & SANCTIONS DOMAINREAD MY BACKGROUND →
386EXPLAINED ANSWERS
131EASY
102MEDIUM
153TRICKY
COVERAGE MAP

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.

SEARCH & FILTER

Build your interview set.

INTERVIEW QUESTIONS

14 matches

Showing 114 · Page 1 of 1

Payment architecture & BA delivery

Payments foundations

  1. TRICKYClearing vs settlementCompare Clearing and Settlement on “What it is”.
    MODEL ANSWER
    DIRECT 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.

  2. TRICKYMX vs MT corporate payment lifecycleCompare ISO 20022 / CBPR+ lifecycle and Legacy MT and transition lifecycle on “Corporate instruction”.
    MODEL ANSWER
    DIRECT 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.

  3. TRICKYOUR vs SHA vs BENCompare OUR and SHA on “Who pays which charges”.
    MODEL ANSWER
    DIRECT 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

  1. TRICKYMT103 vs pacs.008Compare MT103 and pacs.008 on “Standard and syntax”.
    MODEL ANSWER
    DIRECT 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.

  2. TRICKYMT202 COV vs pacs.009 COVCompare MT202 COV and pacs.009 COV on “Message standard”.
    MODEL ANSWER
    DIRECT 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.

  3. TRICKYSerial vs cover routingCompare Serial routing and Cover routing on “Messages involved”.
    MODEL ANSWER
    DIRECT 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

  1. TRICKYRTGS vs deferred net settlementCompare RTGS and Deferred net settlement on “Settlement unit”.
    MODEL ANSWER
    DIRECT 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.

  2. MEDIUMRTGS vs deferred net settlementWhat is the essential difference between RTGS and Deferred net settlement?
    MODEL ANSWER
    DIRECT 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+

  1. TRICKYUnstructured / hybrid vs fully structured addressCompare Unstructured / hybrid address and Fully structured address on “How the data is held”.
    MODEL ANSWER
    DIRECT 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

  1. EASYReconciliationWhat does “Reconciliation” mean in payments?
    MODEL ANSWER
    DIRECT 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.

  2. EASYStraight-through processingWhat does “Straight-through processing” mean in payments?
    MODEL ANSWER
    DIRECT 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.

  3. MEDIUMPayment controlsWhat does the four-eyes or maker-checker control achieve in payment processing?
    MODEL ANSWER
    DIRECT 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.

  4. MEDIUMPayment enginesWhich checks should a payment engine perform before releasing a payment?
    MODEL ANSWER
    DIRECT 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.

  5. EASYClient payment channelsThrough which channels can a bank receive customer payment instructions?
    MODEL ANSWER
    DIRECT 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.