Skip to content

Java model for MT messages

The message model for MT messages is a set of Java classes representing the structure and content of a SWIFT MT (ISO 15022) message. The message model is a central part of the library suited for message creation, parsing and persistence.

It is designed in three layers of specific use; each provides a different level of abstraction.

Prowide Core Model Layers

Persistence - Lightweight Layer

The upper layer is a generic representation for all messages mainly intended for message persistence. The model includes specific attributes for header and trailer information, while the body content (business payload) is kept as a single String attribute (not parsed).

Since this model is generic, message objects can be instantiated without prior knowledge of the specific type of message. This design is therefore optimal for database persistence because all message types can share a simple and efficient database structure. It can be thought of as a wrapper of a swift message file.

Besides message content, the model provides several metadata containers very useful for a message management application, such as a holder for message status, attached notes and extendable properties.

The main classes for this layer are the AbstractSwiftMessage and MtSwiftMessage.

Parse/Build - Functional Layer

The middle layer is a functional view of a specific message, for example an MT103. The provided API allows you to read data from a known message easily, as well as API to build new messages.

This layer provides a specific class for each message type, with getters for its inner sequences and fields. Also a specific class for each possible field of the message, for example Field32A, with methods to retrieve any internal component (subfield), for example the Calendar, Currency and Amount of Field32A.

These specific classes can be thought of as a facade or view of the internal message content.

The entry point for this layer is the AbstractMT and all its subclasses that represent a specific message type.

Notice these objects are not intended for message modification because when you read content with a getFieldNN the returned object is detached from the underlying model. Details on how to modify a message are described later in this document.

NarrativeContainer fields

Some fields, such as Field71B, implements the NarrativeContainer interface and provide methods to access the narrative content in a structured way.

These fields support having a simple unstructured content split in lines and also a structured version with codewords. Where the codewords are separated with slashes and can be used to categorize part of the narrative content.

The internal component structure for these fields is just a plain single String with the whole value. But the structured content can be retrieve using:

  Narrative narrative = f.narrative();

Where the Narrative object provides methods to access the different parts of the narrative by the codewords.

The NarrativeResolver parser can automatically detect the narrative structure and create the Narrative depending on the field value. In most of the fields the only element in the structured format is the actual text. however, some fields can include bank code, currency and amount, country codes or the narrative partitioned as a main narrative and a supplement fragments.

Supported line formats are:

  • Format 1

    • Line 1: /8a/[additional information] (Code)(Narrative)
    • Lines 2-n: /8a/[additional information] (Code)(Narrative) or [//continuation of additional information] (Narrative)

  • Format 2

    • Line 1: /8c/[additional information] (Code)(Narrative)
    • Lines 2-n: /8c/[additional information] (Code)(Narrative) or [//continuation of additional information] (Narrative)

  • Format 3

    • Line 1: /8c/[3!a13d][additional information] (Code)(Currency)(Amount)(Narrative)
    • Lines 2-6: /8c/[3!a13d][additional information] (Code)(Currency)(Amount)(Narrative) or [//continuation of additional information] (Narrative)

  • Format 4

    • Line 1: /8c/[additional information] (Code)(Narrative)

    • Lines 2-3: [//continuation of additional information] (Narrative)

    • Variant for cat 1 with country

    • Line 1: /8c/2!a[//additional information] (Code)(Country)(Narrative)
    • Lines 2-3: [//continuation of additional information] (Narrative)

  • Format 5

    • Line 1: /2n/[supplement 1][/supplement2] (Query Number)(Narrative 1)(Narrative 2)
    • Lines 2-6: /2n/[supplement 1][/supplement2] or [//continuation of supplementary information]

  • Format 6

    • Line 1: /6c/[additional information] (Code)(Narrative)
    • Lines 2-100: /6c/[additional information] (Code)(Narrative) or [continuation of additional information] (Narrative) (cannot start with slash)

  • Format 7

    • Code between slashes at the beginning of a line

  • Format 8

    • Free format codes in slashes, not necessary on new lines

The same Narrative model can be used to create this fields content when building messages from scratch.

Backbone - Structure Layer

The lower layer is the internal backbone of the upper one, and in most cases there is no need to use this API from an application.

The message representation at this level handles the message content as simple tuples of field name and field value and implements low level handling of sequences and blocks. This model is quite simple, generic and loosely coupled to specific messages, therefore being very efficient and requiring minimal construction constraints.

Messages in this layer are represented by the SwiftMessage class, with its internal name-value tuples modeled by the Tag class.

This layer is also the one used for content modification.