The serial flow step by step

Consider a payment from a customer of Bank A in India to a customer of Bank D in Brazil, where the chain is Bank A to Bank B to Bank C to Bank D, and the currency is US dollars. The amount is USD 10,000, the charge arrangement is SHA, and each intermediary bank charges USD 25. In the serial flow, Bank A debits its customer USD 10,000, checks the payment for sanctions and fraud, and sends a SWIFT MT103 customer payment message to Bank B. The MT103 carries the full details, the originator, the beneficiary, the amount, the charges arrangement in field 71A, and the remittance information in field 70. Since the CBPR+ migration, the same serial leg travels as a pacs.008, with the originator in the Dbtr element, the beneficiary in the Cdtr element, and the charges in the ChrgsInf element. Bank B receives the pacs.008, screens it against sanctions lists, and checks its nostro balance. Bank B is the intermediary, so it deducts its charge of USD 25 from the amount, leaving USD 9,975, and sends a new pacs.008 to Bank C for USD 9,975. The accounting at Bank B is: debit its nostro account with Bank A, or credit the amount it owes, by USD 10,000, and credit its nostro account with Bank C by USD 9,975, keeping USD 25 as its charge income. Bank C does the same, deducting USD 25 and sending a pacs.008 to Bank D for USD 9,950. Bank D receives USD 9,950, credits the beneficiary USD 9,950, and sends a confirmation back through the chain. The beneficiary therefore receives USD 9,950, which is USD 10,000 less USD 25 at Bank B and less USD 25 at Bank C. The sender paid USD 10,000 plus Bank A's own fee, and the beneficiary is USD 50 short of the invoice amount. That shortfall is the most common complaint in cross border payments, and it is the direct consequence of the SHA charge arrangement combined with the serial method. If the invoice must be settled in full, the sender should have chosen OUR, and the analyst must be able to explain that to the customer before the payment is sent, not after the supplier complains. Each bank in the serial chain holds the payment for a period while it processes it, and that period is where the time goes. Bank B may take a day to screen, validate and forward, Bank C may take another day, and Bank D may take a day to credit the beneficiary. A payment through three intermediaries can take three to five business days, and each bank adds its own processing time, its own cut off and its own charge. The value date is the date on which the beneficiary receives value, and it is set by the sending bank based on the chain, usually two to five business days after instruction for a serial payment with two intermediaries. The serial flow is simple to understand and easy to trace, because the payment instruction and the funds move together and each bank can see the full chain. The weakness of the serial flow is that it is slow when the chain is long, because each bank processes the payment in turn, and each bank adds its own processing time, its own cut off and its own charge. The serial flow is also vulnerable to a weak link. If one bank in the chain is slow, or if one bank stops the payment for a compliance query, the whole payment is delayed, and the beneficiary bank may know nothing about the payment until it arrives, because the instruction has not yet reached it. Failure modes in serial are specific and the analyst should know them. If Bank B rejects the payment because the IBAN is invalid, it sends a pacs.002 payment status report back to Bank A with reason code AC01, and the funds are not moved, so Bank A can tell the customer immediately. If Bank C stops the payment for a sanctions query, the payment sits at Bank C, Bank A and Bank B may not know, and the customer must wait while the query is resolved. If Bank C deducts a charge that was not expected, the beneficiary receives less than the sender expected, and the shortfall is discovered only when the supplier complains. Each of these is a different exception with a different handling process, and the analyst must design for all of them. For a system design, the serial flow needs the following: a routing table that says which banks are in the chain for each corridor, a charge table that says what each bank deducts, a cut off calendar for each bank in the chain, a screening step at each hop, and a status tracking mechanism that records when each bank received and forwarded the payment. The gpi tracker provides the status tracking for gpi payments, and the UETR links the pacs.008 at each hop to the same payment. Without the UETR, tracing a serial payment means matching amounts and dates by hand, which is slow and error prone. Worked example with real numbers: a bank in Paris sends EUR 100,000 to a beneficiary in Tokyo, and the Paris bank and the Tokyo bank hold accounts with each other, so they are the same correspondent for both directions, and the payment can travel by serial method, with one MT103 passed from Paris to Tokyo directly, because no intermediary is needed. The same payment, sent through a different correspondent, would need an intermediary, would take two days, and would cost EUR 15 plus USD 20 in intermediary charges, so the same-correspondent case is faster and cheaper, and the bank should use it whenever the two banks hold accounts with each other. The serial method is the right choice here, because the chain is short and the banks know each other. Failure and recovery: the same-correspondent case fails when the Paris bank assumes the Tokyo bank still holds its account, but the account was closed, so the payment is sent to a bank that no longer holds the account, and it is returned after two days. The recovery is to check the correspondent account before sending, to use the SSI that names the current correspondent, and to resend through the correct correspondent, but the beneficiary is paid two days late. A bank that does not validate the correspondent account before sending will create this failure, and the BA must require the account to be validated, because a payment sent to a closed correspondent account is a payment that will be returned, and the return costs more than the validation. For a business analyst, product owner or subject matter expert, the serial flow requirement must name the same-correspondent case, state when it applies, and state the validation that the correspondent account is still open. The ISO 20022 pacs.008 carries the same agent chain, and the requirement must map the serial MT103 chain to the pacs.008 agent fields, so the same-correspondent case survives migration. A serial flow that does not check the correspondent account is a serial flow that will return payments, and the test must include a closed-account case.