pain, pacs, and camt checkpoint
Match the three big message families to their jobs and their senders: customer initiation (pain), interbank clearing and settlement (pacs), and cash management and investigations (camt).
QUESTIONS AS TEXT
Q1. Which description correctly maps the three message families?
Answer: A: pain: customer-to-bank payment initiation; pacs: bank-to-bank clearing and settlement; camt: cash management, reporting, and investigation messages.
The families map onto the legs of a payment. The customer instructs their bank with pain messages, banks move the payment between themselves with pacs messages, and camt messages report on accounts and carry investigations. When you see an unfamiliar message, the prefix alone tells you which conversation it belongs to.
Q2. In an SCT-style credit transfer, match each action to the party that performs it.
Answer: Sends a pain.001 to initiate the credit transfer → Debtor (pain.001 is the customer-to-bank initiation message — it can only originate with the paying customer.); Converts the initiation into a pacs.008 and sends it into clearing → Debtor Agent (Turning the customer's pain.001 into an interbank pacs.008 is the debtor agent's job — the moment the payment changes worlds.); Exchanges the interbank message between participants and supports settlement → CSM (The clearing and settlement mechanism sits between the banks: it exchanges the pacs.008 and supports settling what results.); Receives the pacs.008 and credits the beneficiary's account → Creditor Agent (The pacs.008 terminates at the beneficiary's bank — the only institution that can credit the creditor's account.); Sees the incoming credit on their account statement → Creditor (The creditor sends no message in a credit transfer; the credit on the statement is the result, not a step.)
The handoff from pain.001 to pacs.008 is the moment the payment changes worlds: from a customer instruction into an interbank obligation. The CSM sits in the middle of the interbank leg, and the creditor only ever experiences the result — a credit on their account, later visible through reporting messages.
Q3. What is the role of a pacs.002 in an interbank flow?
Answer: A: It is a payment status report: it tells the sender of an interbank payment whether the instruction was accepted or rejected, with reason codes.
pacs.002 closes the loop on an interbank instruction: accepted, rejected, or — in some schemes — intermediate statuses, each with machine-readable reason codes. In instant payment schemes it is the message that makes or breaks the customer experience, because the originator bank needs it before it can tell the customer the payment succeeded.
Q4. A payment settled yesterday. Today two different things could happen: the beneficiary bank sends money back because the account is closed, or the ordering bank asks for the money back because it was sent twice. Which messages carry these two events?
Answer: A: Return of funds: pacs.004. Request to get funds back: camt.056.
The direction of initiative decides the message. When the beneficiary side sends funds back on its own initiative, that is a return: pacs.004, referencing the original payment. When the ordering side wants funds back, it can only ask — camt.056 — and the answer may be a pacs.004 (funds returned) or a camt.029 (resolution, including refusal). A recall request is never a guarantee of recovery.
Q5. A bank receives this fictional fragment. Which family does it belong to, and what leg of the payment is it?
Answer: A: It is from a pain.001 — a customer's instruction to its own bank, on the initiation leg, carrying the instructed amount.
The vocabulary betrays the leg: InstdAmt is the customer's instructed amount, and the debtor-account-plus-transactions structure is how pain.001 groups a customer's instructions. Once the debtor agent accepts this, it will create a pacs.008 for the interbank leg — same payment, different message, different amount semantics. All parties and IBANs are fictional.