Credit transfers, the default business payment

A credit transfer is a payment instruction in which the payer, known as the debtor, instructs the debtor agent to transfer funds to the account of the payee, known as the creditor. The money moves in the direction of the instruction, from payer to payee, and the payer retains control until the instruction is sent. Credit transfers are used for salaries, supplier payments, tax payments, and most cross border customer payments, and they are the basis for both SWIFT MT103 messages and ISO 20022 pacs zero zero eight messages. They are simple to understand, easy to reconcile when remittance data is included, and familiar to every corporate treasurer. A credit transfer can be a single payment or part of a bulk file containing thousands of payments. In a bulk file, each transaction still carries its own debtor, creditor, amount, and reference, but the file is processed as a batch for efficiency. The debtor agent validates the file, checks balances and sanctions, and then routes each payment through the appropriate clearing system. If one transaction in a bulk file fails, the others can still succeed, provided the file structure allows partial processing. Analysts must understand whether a given system processes files atomically, where all succeed or all fail, or item by item, because the exception handling is very different. Credit transfers can also be domestic or cross border, immediate or deferred, and high value or retail. A domestic same day transfer through a national clearing system follows different cut off times and different settlement rules from a cross border transfer through correspondent banks. The core business logic stays the same, however. The debtor instructs, the debtor agent debits, the clearing and settlement systems move value between banks, and the creditor agent credits the beneficiary. Every requirement you write for a credit transfer product should trace back to one of those steps. Follow a bulk salary file. An employer sends one file with 2,500 salary payments totalling Rs 18 crore. The debtor agent validates the file, checks the employer's balance, screens the payees, and processes each payment. One record fails, because an employee's account number has a transposed digit, and the other 2,499 succeed. That is item by item processing, and it is what the employer expects. One bad record should not stop 2,499 salaries. In a system that processes files atomically, the same file would fail as a whole, and nobody would be paid until the file is corrected and resubmitted. Now add a cut off. The file arrives at 5 minutes past 4 in the afternoon, five minutes after the 4 in the afternoon cut off, so the whole run moves to the next working day and 2,500 employees are paid a day late. The employer's payroll team learns to submit by 3 in the afternoon, and the analyst learns to put the cut off in bold in the user guide. For a business analyst, the two questions that matter most about a credit transfer product are how files are processed and when the cut off falls. The requirements must state whether processing is atomic or item by item, what happens to the failed items in each case, and whether the payer is told about them the same day. They must state the cut off times for each channel and each currency, and what happens to a file that arrives late. The test pack should include a file with one bad record among thousands, a file that arrives after cut off, and a single urgent payment sent outside the bulk flow, because those three cases are where credit transfer products most often surprise their users.