INDA vs INGA — One Code, Two Accounting Outcomes 🤔

Same pacs.008. Same amount. One settlement method code apart. In one case, your bank still has to settle. In the other, settlement has already happened. MT to MX is not always a one-to-one field replacement. Some information that used to be implied is now explicit, and it carries business meaning. 🔷 INDA: Settled by the Instructed Agent Your bank is responsible for settlement of this leg. In a typical correspondent arrangement, it may debit the sending bank’s account held on its books before processing the payment onward. 🔷 INGA: Settled by the Instructing Agent The Instructing Agent is responsible for settlement of this leg. Your bank must recognise the agreed settlement arrangement and apply the appropriate accounting treatment—not blindly repeat a posting. 📌 An illustrative migration risk An incoming INGA payment is incorrectly mapped as INDA. The engine follows the wrong settlement logic and debits the sending bank’s account again. The result? Potential double-posting and a reconciliation break discovered at day-end. 💡 The BA lesson During migration, ask: ▪️ Who settles this leg, and who services the relevant account? ▪️ Has settlement already taken place? ▪️ What accounting entries and onward processing should follow? A field mapping tells us where the data goes. Business analysis tells us what it means. 💬 When migrating from MT to MX, are you mapping fields—or validating the business behaviour behind them? #PaymentBA #ISO20022 #CBPRPlus #Payments #BusinessAnalysis