Skip to content

Java model for MX messages

The message model for MX messages is a set of Java classes representing the structure and content of a SWIFT MX (ISO 20022) message. Being the MX standard based on XML, the Java model is an abstraction of the different XMLs defined by the standard with Java classes to represent each possible MX message. A business objects dictionary is part of the MX message model, representing any possible content element of an MX message.

The scope of the message model for MX is the payload composed by the Application Header and the Document (with the actual body of the message). The overhead xml wrappers with transport information are not part of the model and if present, it will be ignored by the parser.

In general the model was designed to mirror as much as possible the Prowide Core API for MT messages. In this sense there are two independent layers or levels of abstraction. The lower one being a generic tree representation of the XML with a node per XML tag. And a more business oriented layer with an implementation of each possible MX message type and business content. Unless explicitly remarked this document refers to the business model.

Basically all MX model code is concentrated in two main packages:

  • com.prowidesoftware.swift.model.mx for all classes that are a main entry point to MX messages, that is, the root class of the message. Reading and Writing a MX message starts by picking a class from this package which represents the message that will be used.
  • com.prowidesoftware.swift.model.mx.dic supporting classes and reused objects for MX classes. These classes are used inside MX root classes.

And for MX system messages another two packages has been added: * com.prowidesoftware.swift.model.mx.sys for the MX system message main classes. * com.prowidesoftware.swift.model.mx.sys.dic for the system messages data dictionary.

Our class model for MX is generated from the standard XSD schemas. However it is not the default output of a jaxb compilation. The process uses several custom plugins in order to produce a special API in the Mx classes to parse XMLs sources with ease. And we also have a special process in the generation to merge the complex types implementation classes into a consolidated single dic package, this is important to avoid producing thousands or repetitive classes (notice the standard schemas does not include any common library for the types so a default jaxb generation per namespace is not feasible when targeting the complete set of message categories and versions).

Class naming

MX messages have this naming structure :

Message bbbb.fff.vvv.nn maps to class MxBbbfffvvvnn where:

  • bbbb: four characters indicating the business process of the message, all available business process can be found in the enum com.prowidesoftware.swift.model.MxBusinessProcess
  • fff: 3 digits indicating the message functionality
  • vvv: 3 digits indicating the message variant
  • nn: 2 digits indicating the message version

For example: MX message trea.001.001.02 is mapped to class MxTrea00100102 MX message camt.003.001.02 is mapped to class MxCamt00300102

The inner elements of the messages are composed by instances of the business dictionary where the model provides a class for each possible type defined in the MX standard for example: AccountParties6, InvestmentAccountOwnershipInformation6, AccountOpeningType1Code, etc...

Supported MX Versions

The library accumulates all historic versions for all message categories. And it is yearly updated with new versions of messages added per SRU.

Hybrid addresses

The message model already supports setting a combination of structured and unstructured content. The acceptance of hybrid address is related to the network validations.

The network will start accepting hybrid addresses starting by the end of November 2025, when the SRU2025 goes live.

Then a year later, by November 2026 only structured content will be accepted.

SWIFT calendar for hybrid addresses

In any case notice the library API will not split unstructured content into structured content.

Automatic structuring of unstructured address content is something that should be achieved with heuristics, based on sample data. As a custom process for each institution because it depends on the institution's data and how the data is collected and maintain in the backoffice and front desk applications.

The SWIFT release calendar is giving enough time to the industry to modernize their system and start collecting and storing the addresses already in a structured way. This means, supporting structured addresses end to end.

Info

Prowide Integrator hybrid addresses handling in SRU2025

  • Validation: The validation component will start to accept the mixed content.

  • Translations: The translation component will generate hybrid addresses whenever possible. If the MT source is structured, the translation will generate a fully structured content in the MX. If the source is unstructured but part of the content is structured, the translation will generate a hybrid address. But finally if the source is unstructured, it will be propagated as is to the translated MX.

Until SRU2025 the model, validation and translation will only accept structured or unstructured content in the MX.