Posting rules

A posting rule is the instruction that tells the ledger which account to debit and which to credit, for how much, in which currency and on which value date, for a given payment event. Every payment type has its own posting rule, and every message type maps to a posting rule, so a pacs.008, a pacs.004 and a camt.056 each post differently. A posting rule that omits any of these is incomplete, and the ledger will either reject the event or post it wrongly. Source: Bank for International Settlements, Committee on Payments and Market Infrastructures; ISO 20022 message definitions for pacs.008, pacs.004 and camt.056. The posting rules for the main payment events follow a pattern that a business analyst can learn once and apply everywhere. For a customer credit transfer, the debtor bank debits the customer account and credits the settlement or nostro account, and the creditor bank debits the settlement or nostro account and credits the customer account. For a recall, no posting is made until the beneficiary bank agrees, and then the entries follow the return pattern. For a fee, the bank debits the customer account and credits fee income, and for interest, the bank debits interest expense and credits the customer account, or the reverse for interest charged. Each rule must be written as a table in the functional specification, with one row per event. A worked example shows a posting rule table in use. A EUR 25,000 SEPA Credit Transfer from Bank A to Bank B posts at Bank A as debit customer deposit EUR 25,000 and credit T2 settlement account EUR 25,000, on the value date, with the pacs.008. At Bank B it posts as debit T2 settlement account EUR 25,000 and credit supplier deposit EUR 25,000, on the same value date, with the same message identifier. If the supplier account is closed, Bank B returns the payment with a pacs.004. The message identifier links all four postings, and the reconciliation can prove that the payment and the return net to zero across both banks. The parties that own posting rules are finance, who owns the chart of accounts and approves every new rule, operations, who posts and reconciles, and the payment hub team, who implements the rule in the engine. A new payment type, a new rail or a new fee cannot go live until finance has approved its posting rule, because the rule decides the balance sheet, the profit and loss account and the regulatory reporting. The rule must be versioned, because a change to a posting rule changes history if it is applied retrospectively, so that an auditor can prove which rule was in force on the day the payment was posted. A hub that hard codes posting rules in the payment engine, without a versioned rule table that finance owns, cannot be changed safely. Failure in posting rules appears as a wrong account, a wrong amount, a wrong value date or a missing reversal. A fee posted to the wrong income account will misstate the profit and loss account, and the error will be found at the month end close. A return posted without reversing the original fee will leave the customer charged for a payment that was returned, and the complaint will be about the fee, not the return. A posting with the wrong value date will calculate the wrong interest, and the correction needs a camt.087 value-date correction. Each failure is fixed by a correcting entry under the reversal rule, never by editing the original posting, and the correction must be approved by finance. The effect on the bank, the customer and operations is that posting rules are the contract between the payment engine and the ledger. For the customer, the rule decides what appears on the statement, when it appears, and what the balance is. For operations, the rule decides the reconciliation: the ledger must agree with the settlement statement, the nostro statement and the clearing file, and any difference is a break that must be investigated. A business analyst must therefore write the posting rule table as part of the requirement, with finance as the approver, and must test every rule with a worked example before the product goes live. For a business analyst, product owner or subject matter expert, the test is to produce the posting rule table for a new product and to walk a payment, a return, a recall, a fee and a charge through it. Ask what happens when the debit posts and the credit fails, and how the system recovers without posting twice. Ask how the rule is versioned, who approves a change, and how the change is tested. The ISO 20022 messages provide the trigger and the reference, but the posting rule provides the accounting, and the two must be specified together in the functional specification, with the message identifier as the link between them. Posting rules also cover non-booking events, which are taught in the next lesson, and the distinction must be kept clear. A hold, a reservation or a memo does not change the ledger balance, so it does not post, but it does change the available balance, so it must be recorded. A payment that is authorised but not yet cleared posts a hold, not a debit, and the debit is posted only when the clearing file arrives. A payment that is queued for a cut-off posts nothing until it is released, and the release is the posting trigger. A requirement that confuses a hold with a posting will overstate the ledger balance, understate the available balance, and produce a reconciliation break that operations cannot explain without reading the code. Takeaway: a posting rule names the event, the trigger, the debit account, the credit account, the amount, the currency, the value date and the reversal rule, and finance owns and versions it. Every payment type and every message type has its own rule, and the message identifier links the message to its postings. Write the table before building the flow. Further reading: Bank for International Settlements, Committee on Payments and Market Infrastructures, A glossary of terms used in payments and settlement systems; ISO 20022, pacs.008, pacs.004 and camt.056 message definitions. Last reviewed 7 November 2026.