Business Application Header
Decoding the Digital Envelope: Explaining the Business Application Header
Welcome to The Engineer Banker, a weekly newsletter dedicated to organizing and delivering insightful technical content on the payments domain, making it easy for you to follow and learn at your own pace
In our initial exploration of ISO20022, we delved into the details of customer credit transfers within ISO20022 infrastructures. During that discussion, we touched upon the various ISO message types, such as pacs, admi, camt, pain, and others, which play pivotal roles in facilitating interbank transactions and enabling specific payment flows. Today, we aim to delve deeper into a particular technical aspect that we previously glossed over to maintain a streamlined narrative. We will be shedding light on the Business Application Header, a standardized header that is embedded within all these messages. This header is crucial as it provides essential metadata about each transaction, ensuring seamless communication and processing across the interbank space. Join us as we unpack the significance and workings of this integral component in the world of ISO20022. If you're just diving into the ISO20022 real-time payments systems, we highly recommend starting with these three foundational articles:
A ISO20022 message contains two parts the Business Application Header (head.001) and the ISO Business Message itself (eg. pacs, camt, pain,…).
BAH is sent with ALL ISO 20022 messages: pacs, camt, pain, admi,…
The Business Application Header (BAH) in the ISO 20022 standard is a component that provides essential information about the message being transmitted. It's like a metadata about the message that contains details about the sender, receiver, message type, and other crucial information, ensuring that the message is processed correctly by the recipient's system. It is important to note that the BAH does not travel end to end, the central infrastructure extracts the message from its business application header and subsequently encapsulates it with an outbound business application header. Lets see this idea with an example from FedNow:
One of the notable advantages of utilizing this header is its flexibility. If the RTP or FedNow infrastructure needs to append additional data or information to the message, they can seamlessly do so incorporating the data in the business header as opposed to amend the original message. This ensures that the integrity of the original message is preserved, as it remains untouched and immutable, while still accommodating the necessary modifications or additions.
The BAH is used for:
Routing: It helps in determining where the message should be sent and how it should be processed upon arrival.
Identification: It provides unique identifiers for the message, aiding in tracking and reconciliation.
Message Management: It offers details like timestamps, which can be crucial for time-sensitive operations or for understanding the sequence of events.
Security: By identifying the sender and receiver, it can assist in authentication and authorization processes, also the BAH can contain the cryptographic signature of the business message.
Examples of elements you might find in a Business Application Header include:
From: Identifies the sending application.
To: Identifies the receiving application.
Business Message Identifier: A unique ID for the message.
Message Definition Identifier: Indicates the type of message being sent (e.g. pacs.008.001.08).
Creation Date: Timestamp of when the message was sent.
Possible Duplicate: Indicates if the message is an original or a copy.
Signature: Ensures integrity, guaranteeing the message remains unaltered, and establishes non-repudiation, confirming with certainty that the message originated from the specified institution.
In essence, the Business Application Header ensures that the message is delivered correctly, processed in order, and can be tracked and authenticated, making it a fundamental part of the ISO 20022 standard. Take a look at the illustrative example of this header below:
<AppHdr xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.01">
<Fr>
Sending institution identifier
</Fr>
<To>
Receiving party identifier, eg. FedNow
</To>
<BizMsgIdr>e5465b5c-627f-42f0-9768-26e3f2b9dfb8</MessageId>
<MsgDefIdr>pacs.008.001.08</MsgDefIdr>
<CreDt>2023-08-19T14:33:10Z</CreationDate>
<PssblDplct>false</MessageType>
<Sgntr>Encoded signature payload</Sgntr>
</AppHdr>In this context, the 'receiving party identifier' doesn't refer to the beneficiary institution. Instead, it denotes the application processing the message, such as FedNow in our example. When FedNow subsequently forwards the ISO message to the intended recipient, they label the 'From' field as 'FedNow' and populate the 'To' field with the actual receiving party's identifier.
It's crucial to highlight that within certain ISO 20022 real-time implementations, those that support the retrieval request feature (admi.006 message), there's a specific process in play. When invoking the retrieval request for a previous message, not only is the original message fetched, but the original business header associated with that message is also returned. This combined data is then transmitted with a fresh business header, in line with the standard retrieval request flow. However, there are instances where the desired message might not be located within the system. In such scenarios, an admi.002 message is dispatched in response. It's essential to interpret this as a rejection, indicating that the requested message couldn't be retrieved. This use case should be infrequently employed, reserved for those unique instances when the institution must cross-reference messages with FedNow, particularly those that were transmitted due to technical anomalies or errors.
We've discussed how the business application header serves as a crucial link between the network header and the ISO message, however, it's essential to remember that based on the specific implementation, you might observe variations in the fields utilized within the business application header.