admi messages: the administration layer of ISO 20022

Administration messages, the admi set in the ISO 20022 catalogue, carry no payment value at all, and that is exactly why they matter: they keep the messaging system itself alive, acknowledged and recoverable. An admi message tells a counterparty that a system event happened, asks for a message to be resent, or confirms that a message was received, and without them a bank cannot tell the difference between a payment that was never sent and a payment whose acknowledgement was lost. The set includes admi.002 SystemEventNotification, admi.004 SystemEventAcknowledgement, admi.006 ResendRequest and admi.007 ReceiptAcknowledgement. Source: ISO 20022 catalogue, admi message definitions, and SWIFT CBPR+ usage guidelines. Why a separate administration layer exists is that payment messages and system messages fail in different ways and need different handling. A pacs.008 that is rejected for a business reason returns a pacs.002 with a reason code, and the business teams act on it. An admi.002 that reports a system event, for example a planned outage or a cut-off change, is not about one payment, it is about every payment that will flow through the affected system, and operations must act on it before the payments fail. Mixing the two would mean a business rejection could be mistaken for a system outage, or a system event could be treated as one failed payment, so the catalogue keeps them apart by design. The parties to an admi exchange are the sender and receiver of the original message, plus the system operator in the middle, and each has a different duty. The sender must be able to prove what it sent and when, the receiver must acknowledge receipt, and the operator, for example SWIFT or a market infrastructure, must record the event and tell affected participants. In a correspondent chain the admi exchange happens between each pair of directly connected parties, not end to end, so a resend request from Bank B to Bank A is about the leg between them only, and Bank B must still manage its own leg to Bank C separately. A business analyst who maps an admi flow must therefore draw it per hop, not per payment. How admi.006 ResendRequest works shows the mechanics. Bank B expects a pacs.008 from Bank A with a given business message identifier, and by 11:00 it has not arrived, although Bank A claims it was sent at 10:42. Bank B sends admi.006 naming the missing message identifier and the expected creation date, and Bank A responds by resending the original message with the same identifier, not a new one, so that the receiver can detect the duplicate if the original arrives late. The resend is a copy, not a new payment, and if the original later arrives the receiver must discard the duplicate by identifier, which is why the business message identifier must never change on a resend. This is the same idempotency discipline that instant payment systems enforce with their own identifiers. Success looks quiet: the admi.007 ReceiptAcknowledgement confirms delivery, the admi.004 acknowledges a system event, and no human ever sees either message, because the operations dashboard shows green and the payment flow continues. The value of admi is visible only in the counterfactual, which is what a 15-year SME must be able to explain to a project board: without acknowledgements, a bank would have to phone its counterparty to confirm every payment arrived, and without resend requests, a lost message would sit undetected until a customer complained. The admi layer is the reason a bank can prove, at 17:00, that every message it sent today was received, and can list the ones that were not. Failure of the administration layer itself is the hardest failure to diagnose, because the tool that reports failure is the thing that failed. 007 acknowledgements stop arriving, the sender cannot tell whether its payments are lost or only the acknowledgements are lost, and the correct response is not to resend every payment, which would create duplicates, but to check the connection and the message queue, confirm with the counterparty through a second channel, and resend only the messages the counterparty confirms it never received. A worked example: Bank A sent 40 pacs.008 messages and then sent admi.006 for the two unacknowledged identifiers; the counterparty confirms one was received and one was lost, so only one is resent, and the duplicate risk is contained to zero. The data in an admi message is deliberately small: message identification, the related message reference, the event code or reason, and the creation date and time. There is no amount, no currency, no debtor and no creditor, because an admi message is about a message, not about money. For a BA writing requirements, the fields to specify are the correlation identifiers, the timeout after which a missing acknowledgement triggers an admi.006, the maximum number of resend attempts, and the escalation path when resends keep failing. The timeout matters commercially: a 30-minute timeout means a missing payment is discovered within the hour, while a next-day timeout means the customer complains first, and the business must choose the timeout, not the developer. On success, the effect on the bank is an auditable trail that every message was delivered or explicitly chased; on the customer it is invisible, which is the point; on operations it is a dashboard that turns from green to amber the moment an acknowledgement is overdue. On failure, the effect is a payment that sits in an unknown state, a customer who cannot be told where the money is, and a reconciliation break the next morning when the statement does not match the sent file. The cost of a weak admi implementation is therefore measured in customer calls and manual investigation hours, not in message fees, and a business case for fixing it should count those hours. What a BA, PO or SME must understand is that admi is not a side topic for the messaging team, it is the control that makes every other message trustworthy. When a stakeholder asks why a payment went missing, the first evidence is the admi trail: was it sent, was it acknowledged, was it resent, and who confirmed receipt. A requirement that specifies a payment flow without specifying its admi handling is incomplete, because it describes the happy path only. The test is simple: for every message in the flow, name the acknowledgement, the timeout, the resend rule and the escalation, and if any of those is missing, the flow is not ready for production. Further reading: ISO 20022 catalogue admi messages; SWIFT CBPR+ usage guidelines on message handling. Last reviewed 7 November 2026.