“Binding” the BAH

The Business Application Headers (BAHs) are a set of ISO 20022 Message Definitions, which have information common across business scenarios. They are indended for use with other ISO 20022 Message Definitions, so that they need not redefine the same information, and to ensure consistency.

However there is no standard way to “bind” an instance of a BAH to a business message. This page discusses several approaches. In an ISO 20022 Regitration Management Group (RMG) resolution 15/326 « RMG resolve to request the TSG to incorporate recommendations for the binding of the BAH to an ISO 20022 messages into their active work on ISO 20022 compliance. »

TSG has agreed that the BAH is in the business layer of the protocol, not the transport layer.

Options:

1. Binding envelope that contains an application header and a message

2. Binding in the document: the BAH becomes part of the message

3. Binding in the document: the BAH is put in the Supplementary Data

4. Binding outside the document importing choice of BAH

1. Binding envelope that contains an application header and a message

There are several approaches within this option to creating an envelope.

Simple envelope in XML Schema

A simple envelope element and type which contains a sequence of an element from a header namespace, and an element from the international repository namespace.

However, ISO220022-4:2013 specifies generation of each message schema with a separate target namespace. Instead we’d have a versioned envelope schema which is bound to the target namespace of a specific BAH.

Alternatively we could make a generic envelope with two element in any namespace.

Model envelope as ISO 20022:2013 message

We could also model and generate the envelope as per ISO20022:2013,
whereby the envelope has elements whose types are external schema for any namespace.

Model envelope as ISO 20022+ message

Fixing to XML generation to remove the Extraneous rootElement type:

It’s better to restrict the content of the element to messages to a namespace for the IRI of the repository/package.

2. Binding in the document: the BAH becomes part of the message

The BAH could become part of the message :

  • by generation – put a header building block in the schema.
    This would require a change to part 4 of the standard.
  • by modelling – add a header building block to the definition
    No change to standard required. Just change modelling practice.

Whether by modelling or generation, add a header building block whose type is :

  1. a specific BAH version.
    Different BAH versions would require different versions or flavours of messages.

  2. an external schema permitting namespaced content.
    ISO20022-4:2013 generates unique target namespace per message, so is the same as a specific BAH version. We could change generation to set the target namespace to the IRI of the repository or package.

  3. an external schema permitting any content.
    Even if process contents is set to strict, ensuring the header is a recognised BAH is an extra step.          

Business Message modelled with specified BAH

Modelling the BAH as an optional element of a specific version of BAH.
does not require a change to standard.


Business Message with Modelled BAH as external schema in any NS

Modelling the BAH as an optional element of an external schema.
This is probably the best approach without requiring a change to standard.

Trimmed Business Message with Modelled BAH as external schema in a NS


This would require specific changes to the standard. Fix modelling so that the root element is the name of the message (not just Document). Fixing generation so that the extraneous root element type level isn’t created. Specify the BAH in a header repository/package so that only registered headers are valid.

3. Binding in the document: the BAH is put in the Supplementary Data

The exaple message selected does not have Supplementary Data,
so this methods can’t be used.

4. Binding outside the document importing choice of BAH

Use one single namespace for the BAH. This namespace would contain all versions of the BAH, and therefore evolve over time to be updated when new versions of the BAH would be created.

The BAH schema allows to use one of the versions of the BAH, e.g. by defining a choice complextype that defines one element per version of the BAH.

In the message schema, the BAH schema namespace is imported, and a BAH element is defined typed by the choice complextype from the BAH

  1. This method allows to decouple the lifecycle of the message and the BAH.
  2. It fully leverages the “Schema Definition language”.
  3. It introduces the import of a namespace in the message schema, which has not been done so far.
  4. We introduce a BAH schema that evolves over time. This is also new compared to what we are used to.

Summary

There are several approaches to binding the BAH to a Business Message.
As ISO 20022-4:2013 generates each message definition in a separate,
the only viable options available now are to:

  • define an envelope with elements from any namespace;
  • have Message Definitions include a Message Building Block:
    • containing an element from any namespace, OR
    • of a specific versioned BAH type.

If we were to change the XML Schema generation method,
so that the target namespace was the IRI of the repository/package,
then we could:

  • define an envelope with elements from specified namespaces
    to restrict the head to BAH, and body to registered messages;
  • have Message Definitions include a Message Building Block:
    • containing an element from the BAH namespace.