The Canonical Model: Core Entities and Fields

At the centre of the canonical model sits the payment instruction, the single record that represents one instruction to move money. It carries a unique payment identifier, the instruction type, such as a customer credit transfer, a direct debit, or a bank to bank transfer, and the current status, such as received, validated, screened, released, settled, or rejected. It also carries the source channel, the time the instruction was received, the requested execution date, and the priority, such as normal or urgent. This central record is the anchor that every other entity connects to, and it is the record that operations teams search for when a customer asks where a payment is. The parties entity describes every person or company connected to the payment, and each party has a clear role. The debtor is the account holder who pays, the creditor is the person or company who receives, and the ultimate debtor or ultimate creditor may be different when a payment is made on behalf of someone else. For example, a payroll company may be the debtor on the instruction while the employer is the ultimate debtor, and a marketplace may be the creditor while the individual seller is the ultimate creditor. Each party carries a full legal name, an address, and an identifier such as a company registration number or a customer number, so the bank can screen and report accurately. The accounts entity describes where the money comes from and where it goes. The debtor account is identified by an IBAN such as GB29 NWBK 6016 1331 9268 19 for a United Kingdom account, or by a domestic account number and sort code where IBAN is not used. The creditor account uses the same approach, for example DE89 3704 0044 0532 0130 00 for a German account at Deutsche Bank. The model also records the account currency, the account holder name as held by the bank, and whether the account is a current account, a savings account, or a corporate operating account. Storing accounts in this structured way prevents the classic error of sending money to a name without a verified account. The amount and currency fields are stored with full precision and with the rules that govern them. The instructed amount is the amount the customer asked to send, for example EUR 8,750.00, and the equivalent amount is the value after conversion when the debtor account is in a different currency, for example GBP 7,421.36 at an agreed rate of 0.8482. The model records the currency code, the number of decimal places, the exchange rate, the rate date, and the charge bearer, such as shared, debtor, or creditor. It also records each charge separately, so a payment of EUR 8,700.00 after a EUR 50.00 fee can be explained line by line instead of appearing as an unexplained difference. The remaining fields give the payment its purpose, timing, and traceability. The payment purpose may be a code such as SUPP for supplier payment or SALA for salary, plus a free text description such as payment for invoice INV-2026-1147. The execution date is the date the bank should release the money, the value date is the date the creditor should receive value, and the settlement date is the date the bank expects final settlement. The end to end reference, such as INV-2026-1147, travels with the payment to the creditor, while the instruction identifier is used inside the bank. Together these fields let a payment be explained, searched, and reconciled years later.