A complete cross border payment: putting it together

Consider a company in Bengaluru that needs to pay a supplier in Frankfurt EUR 10,000 for a shipment of machinery, and the company holds rupees. The company logs into its bank's portal, enters the supplier's name, IBAN and the invoice reference, enters EUR 10,000 as the amount to be received by the supplier, and chooses OUR, because the invoice must be settled in full. The portal shows the exchange rate, the rupee amount to be debited, the charges, and the expected delivery time of one to two business days. The company confirms, the bank debits the rupee account, converts the rupees to euros at the agreed rate, and generates a UETR for the payment. That UETR is shown on the confirmation screen and on the receipt, so the company can track the payment. The exchange rate in this example is 90.00 rupees per euro, and the mid market rate is 89.50, so the spread is 0.50 rupees per euro, which on EUR 10,000 is 5,000 rupees. The company pays 900,000 rupees for the euros, plus the bank's transfer charges. The bank debits the company account 900,000 rupees plus charges, credits its own foreign exchange position, and creates a euro payment of EUR 10,000. The payment is a pacs.008, with the originator in the Dbtr element, the supplier in the Cdtr element, the amount in the IntrBkSttlmAmt element, the charge code OUR in the ChrgsInf element, and the UETR in the UETR element. The pacs.008 is sent to the bank's euro correspondent in Frankfurt. The euro correspondent receives the pacs.008, screens it, and sends it through the SEPA system to the supplier's bank. The supplier's bank receives the instruction directly, sees the UETR, the originator information and the full amount, and prepares to credit the supplier. The funds travel through the correspondent chain, each bank updates the gpi tracker, and the supplier's bank confirms the credit through gpi, sending a pacs.002 with status ACCC, accepted credit completed. The company in Bengaluru can track the payment on the portal, seeing that it has been received by the intermediary bank, that it has been forwarded, and that it has been credited to the supplier. The supplier receives exactly EUR 10,000, because the charge arrangement was OUR and the rate was fixed at instruction time. The company receives a receipt showing the rupee amount debited, the rate, the spread, the charges and the UETR, and the payment is reconciled in the company's books against the invoice reference. The receipt shows the rupee debit of 900,000 rupees plus charges, the euro amount of EUR 10,000, the rate of 90.00, the mid market rate of 89.50 for comparison, and the UETR. The company can give the UETR to the supplier, who can ask their own bank about the same payment. The payment is complete, the invoice is settled, and both sides have a record that agrees. Now consider what happens if the same payment had been sent with SHA instead of OUR. The company would have paid 900,000 rupees plus the sending bank's charge, and the supplier would have received EUR 10,000 less the correspondent charge and less the supplier's bank charge. If the correspondent charged EUR 25 and the supplier's bank charged EUR 15, the supplier would have received EUR 9,960, and would have been EUR 40 short of the invoice. The supplier would have asked for the missing EUR 40, and the company would have had to send a second payment, incurring more charges and another spread. That is why the choice of OUR matters, and why the analyst must ensure that the payment screen explains the difference between OUR and SHA before the customer confirms. This example brings together every topic in the chapter. The charge arrangement decides what the beneficiary receives, the foreign exchange conversion decides what the sender pays, the serial or cover method decides how the funds travel, the UETR makes the payment trackable, gpi makes the journey visible, and transparency makes the cost clear before the customer confirms. A business analyst who can walk through this example, explain each step, and answer the questions that arise at each step, has understood cross border payments at a practical level. The next chapter builds on this foundation by looking at what happens when the payment does not go as planned. The analyst should also be able to vary the example and explain the result. What if the payment is sent on a Friday afternoon. It will not arrive until Tuesday, because of the weekend and the SEPA cut off times. What if the supplier's IBAN is wrong. The payment will be rejected with a pacs.002 and reason code AC01, and the funds will be returned. What if the payment is stopped for a sanctions query. It will sit with the correspondent bank while the query is resolved, and the company must be told. What if the euro correspondent has insufficient liquidity. The payment will queue until funding arrives. Each of these variations is a real scenario, and the analyst who can explain them is the analyst who understands cross border payments, not just the theory but the practice. The final check for the analyst is to trace the example backwards from the beneficiary. The supplier received EUR 10,000. Where did it come from. It came from the supplier's bank, which received it through SEPA from the euro correspondent, which received a pacs.008 from the Indian bank, which debited the company 900,000 rupees and converted them to euros. Each step has a message, a debit, a credit, and a timestamp, and each step can be verified. That is the discipline of cross border payments: every movement of money has a message, every message has a reference, and every reference can be traced. The analyst who can trace a payment backwards is the analyst who can find a payment that is lost, and that is the skill that matters most in operations. Worked example with real numbers: a complete cross-border payment from a buyer in Paris to a supplier in Mumbai, USD 120,000, uses two covers, because the Paris bank splits the cover for liquidity: USD 70,000 through New York and USD 50,000 through London. The buyer pays OUR, so the supplier should receive USD 120,000 in full. The New York cover deducts USD 15, and the London cover deducts USD 12, both in error under OUR, so the supplier receives USD 119,973, a shortfall of USD 27. The complete payment therefore teaches two lessons: the covers must be matched by UETR and totalled, and the charges on each cover must be checked against the OUR arrangement, because each cover is a separate opportunity for an error. Failure and recovery: the complete payment fails when the two covers are not matched, so the Mumbai bank credits USD 70,000 when the first cover arrives, and holds the USD 50,000 when the second arrives, and the supplier receives two credits, USD 70,000 and USD 50,000, instead of one credit of USD 120,000, and reconciles neither, because the invoice was for USD 120,000. A bank that credits per cover, instead of per customer payment, will create this failure, and the BA must require the credit to be per customer payment, not per cover, because the customer payment is the obligation, and the covers are only the funding. For a business analyst, product owner or subject matter expert, the complete payment requirement must name the multiple cover matching, the total check, the per-customer-payment credit, and the charge check on each cover. The ISO 20022 pacs.008 is the customer payment, and the pacs.009 COVs are the covers, and the requirement must map the MT202 COV references to the pacs.009 COV references, so the matching survives migration. A complete payment that is tested with one cover is a complete payment that has not been tested, and the test must include two covers, with a charge error on one of them.