Payment Identifiers, Parties, Accounts and Amount Precision

Every payment carries several identifiers, and each one has a different job. The message identifier, such as MSG-2026-1105-004821, identifies one message in one system. The instruction identifier, such as INSTR-884120, identifies one payment instruction inside that message. The end to end reference, such as INV-2026-1147, is chosen by the customer and travels unchanged to the creditor so the creditor can match the payment to an invoice. The unique end to end transaction reference, known as the UETR, is a globally unique value such as 8f2a1c4e-6b3d-4a9f-8e21-5c7d3a9b1e04 that follows a SWIFT payment across every bank in the chain. Using the right identifier at each step is essential, because searching by the wrong one can return a different payment. Party identification must be precise enough for screening, reporting, and customer service. The debtor name must match the account holder name held by the bank, for example Emma Wilson, and the creditor name must be the full legal name, for example Schneider GmbH, not a shortened trading name. The address should include the street, town, postcode, and country code, such as Musterstrasse 12, 10115 Berlin, DE, because sanctions screening uses the country and town as well as the name. Where a legal entity identifier is available, such as 529900T8BM49AURSDO55 for a large company, it should be stored alongside the name. A payment with a vague party name, such as supplier, cannot be screened properly and cannot be explained to an auditor later. Account identification must distinguish between the account number, the bank, and the account holder. An IBAN such as FR14 2004 1010 0505 0001 3M02 606 identifies the country, the bank, the branch, and the account in one string, and its check digits catch most typing errors. A United Kingdom domestic payment uses a sort code such as 60-16-13 and an account number such as 31926819, and those two values together identify the account. A United States payment may use a routing number such as 021000021 and an account number. The canonical model stores the account in its native format and also stores the derived IBAN or local equivalent, so the payment can be routed correctly whichever system receives it. Amount precision depends on the currency, and the model must enforce the correct number of decimal places for every currency it handles. EUR and GBP and USD use two decimal places, so EUR 8,750.00 is valid and EUR 8,750.005 is not. JPY uses zero decimal places, so JPY 125,000 is valid and JPY 125,000.50 is not. BHD, KWD, and OMR use three decimal places, so BHD 1,250.500 is valid. The canonical model stores amounts as decimal values with the currency code attached, never as floating point numbers that can introduce tiny errors, and it validates the amount against the currency table before the payment is released. That discipline keeps ledgers balanced to the cent. Charges and deductions must be recorded separately from the instructed amount, because the creditor needs to know what was sent and what was taken. A customer may instruct EUR 10,000.00 with charges shared, so the debtor pays a fee of EUR 25.00 and the creditor receives EUR 10,000.00. With charges borne by the debtor, the debtor pays EUR 10,025.00 and the creditor still receives EUR 10,000.00. With charges borne by the creditor, the debtor pays EUR 10,000.00 and the creditor receives EUR 9,975.00 after a EUR 25.00 deduction. The canonical model records each charge with its type, amount, currency, and bearer, so the statement, the settlement record, and the reconciliation all tell the same story.