The business model behind the messages

Behind every ISO 20022 message is a business model that defines the concepts, the relationships, and the rules that the message expresses. The model is maintained in a central repository, and it includes business components such as Party, Account, Amount, and Payment Instruction, and business elements such as Name, Postal Address, and Identification. Each component has a definition, a set of elements, and a set of relationships to other components. For example, a Party can have a Postal Address, an Identification, and a Contact Details, and a Payment Instruction can have a Debtor, a Creditor, a Debtor Agent, and a Creditor Agent. This model is the single source of truth for what each message means. The benefit of a shared business model is consistency. When a pain zero zero one payment initiation uses the same Debtor definition as a pacs zero zero eight clearing message, there is no need to map between different definitions, and the data can flow from initiation to clearing without loss or reinterpretation. The model also supports extension. A scheme can add a new element or a new code list for its own needs, while still reusing the core components. That flexibility is important for domestic schemes that have local requirements, such as a specific purpose code or a local account identifier, but still want to be compatible with the global standard. For an analyst, the business model is a tool for writing clear requirements. Instead of saying field X must contain Y, you can say the debtor name must be populated from the customer master data, and the debtor account must be the account from which the payment is debited. That language is meaningful to business stakeholders, to developers, and to testers, because it describes the business concept, not just the XML tag. When you encounter a new ISO 20022 message, start with the business model, understand the parties and the flow, and then look at the XML. That order will help you understand the message far more quickly than starting with the tags. Worked example with real numbers: a payment of EUR 50,000 involves four business concepts, a debtor, a creditor, an amount and an account, and ISO 20022 defines each once in a central dictionary, so that a pain.001, a pacs.008 and a camt.053 all use the same definition of a debtor. When the corporate customer sends a pain.001, the debtor is Acme Manufacturing SARL with account FR7630006000011234567890189. When Bank A sends a pacs.008, the debtor is the same Acme Manufacturing SARL with the same account. When Bank B sends a camt.053 statement, the debtor is the same party again. If each message had defined the debtor differently, the payment would need manual repair at each step, and the straight through processing rate would fall. Failure and recovery: a business model failure happens when a message uses a party that the model does not define, for example an ultimate debtor who is different from the debtor, but the message carries only the debtor, so the ultimate debtor is lost, and the beneficiary cannot reconcile the payment to the correct legal entity. The recovery is to use the ultimate debtor element in the pacs.008, which the model provides, and to map it from the pain.001 and to map it through to the pacs.008. A third failure is an account that is identified by a proprietary number instead of an IBAN, so the receiving bank cannot route it, and the recovery is to enrich the account with the IBAN from the reference data before the message is created. For a business analyst, product owner or subject matter expert, the test is to draw the business model for a payment, with parties, accounts, amounts, references and purpose, and to show how the model is expressed in each message, pain.001, pacs.008, pacs.002 and camt.053. The model is the single source of truth, and the messages are views of it, so a requirement that describes only one message, without the model, will produce messages that disagree with each other. The ISO 20022 business model, published on iso20022.org, is the source for the definitions, and the requirement must cite it, with the message definitions that reuse each concept, so that a developer can trace any field to its definition.