The messages exchanged in the SCT scheme: pain, pacs, camt

All SEPA messages are based on ISO 20022, using XML syntax. The European Payments Council publishes three main documents for each scheme, the rulebook, the Customer-to-Bank Implementation Guidelines, and the Interbank Implementation Guidelines. New versions are usually published every year in November. The messages flow in two spaces. The customer-to-bank space is where customers and banks exchange messages. The interbank space is where banks exchange messages among themselves, directly or through a clearing and settlement mechanism. An analyst must know which space each message belongs to, because a message used in the wrong space will be rejected. Follow the full message chain for one SCT payment of 25,000 euro from Munich to Lyon, in order. First, the customer sends a pain.001, Customer Credit Transfer Initiation, to the payer bank. Second, the payer bank replies with a pain.002, Customer Payment Status Report, confirming acceptance with status ACCP. Third, the payer bank sends a pacs.008, FI to FI Customer Credit Transfer, to the payee bank through STEP2. Fourth, the clearing system and the payee bank return pacs.002 status reports as the payment moves through ACSP to ACSC. Fifth, the payee bank credits the payee and the status becomes ACCC. Sixth, the payee bank sends a camt.054, Bank to Customer Debit Credit Notification, to tell the payee about the credit. Seventh, the credit appears on the payee's camt.053, Bank to Customer Statement. Seven messages, two spaces, one payment, and every one of them carries the same end to end reference so the chain can be followed. In the customer-to-bank space, messages sent from customer to bank are orders or instructions. Messages sent from bank to customer are reporting. The bank informs the customer about the execution of its payments. In the interbank space, banks exchange messages directly or through a CSM such as EBA STEP2. The message names all begin with four letters inherited from ISO 20022. PAIN stands for Payment Initiation. CAMT stands for Cash Management. PACS stands for Payment Clearing and Settlement. The four letter prefix tells the analyst which family the message belongs to, and the number tells them which message it is. Pain messages are used exclusively in the customer-to-bank space. A customer sends pain.001, Customer Credit Transfer Initiation, to instruct its bank to make a credit transfer. The bank replies with pain.002, Customer Payment Status Report, to report whether the instruction was accepted, rejected, or completed. A customer sends pain.008, Customer Direct Debit Initiation, to instruct its bank to collect a direct debit. A customer sends pain.007, Customer Payment Reversal, to reverse a direct debit it collected in error. Pain messages are never used between banks. An analyst who sees a pain.001 in an interbank flow has found a defect. Camt messages appear in both spaces. In the customer-to-bank space, camt messages inform the customer about its cash position as a result of executed instructions or received payments. Camt.052 is the Bank to Customer Account Report for intraday positions. Camt.053 is the Bank to Customer Statement for end of day positions. Camt.054 is the Bank to Customer Debit Credit Notification for a single booking. Customers can also send camt messages to cancel orders. In the interbank space, camt messages are used to cancel orders or transactions and to reply to cancellation requests, for example camt.056, FI to FI Payment Cancellation Request, and camt.029, Resolution of Investigation. The same camt.056 that a payer bank sends to recall a payment is answered by the payee bank with a camt.029, which states whether the recall is accepted or refused. Pacs messages are used exclusively in the interbank space. They transfer money from one financial institution to another. Pacs.008, FI to FI Customer Credit Transfer, is the SCT interbank message. Pacs.009, Financial Institution Credit Transfer, is the bank to bank message. Pacs.003, FI to FI Customer Direct Debit, is the SDD interbank message. Pacs.004, Payment Return, sends money back after settlement. Pacs.007, FI to FI Payment Reversal, reverses a direct debit. Pacs.002, FI to FI Payment Status Report, reports the status of any of these. The numbers after the name carry meaning. In pacs.008.001.02, 008 is the message number, 001 is the variant, and 02 is the version. The analyst must quote the full version in requirements, because a pacs.008.001.02 and a pacs.008.001.08 are different messages with different fields. Only a subset of ISO 20022 message elements is allowed in SEPA messages, and SEPA rules further restrict some fields. For example, a party name can have up to 140 characters under ISO 20022 rules, but in SEPA only 70 characters are allowed. Remittance information is limited to 140 characters. These differences are highlighted in the Implementation Guidelines for each scheme, and the analyst must design the screens and the validations around the SEPA limits, not the ISO 20022 limits. A customer name of 90 characters is valid ISO 20022 and invalid SEPA, and a payment screen that accepts it will produce a pacs.008 that the clearing system rejects. A field level example makes the restriction concrete. In the pacs.008 for our 25,000 euro payment, the group header carries the message identification and the creation date time. The payment information block carries the debtor, the debtor account with the IBAN, the debtor agent with the BIC, and the charge bearer, which for SCT is always the debtor, because the full amount must be credited. The credit transfer transaction information block carries the creditor, the creditor account with the IBAN, the creditor agent, the instructed amount of 25,000 euro, the purpose code, and the remittance information with the invoice number. Each block has mandatory, optional and conditional fields, and the implementation guidelines state which are which. The analyst's field mapping document should list every field in the pacs.008, state whether it is mandatory, optional or conditional, state the SEPA length limit, and state where the value comes from. The analyst checklist for SEPA messages has four items. First, the message chain for each scheme, listing every message in order with its sender and receiver. Second, the field mapping for each message, with the SEPA limits and the source of each value. Third, the status flow, with the pacs.002 status at each stage and the reason code for each rejection and return. Fourth, the statement and notification design, stating when a camt.054 is sent and what the camt.053 contains. A message design that answers all four is a design that will pass scheme certification, because certification tests exactly these things.