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.