Interpret
Identify the message type, required fields and source-system assumptions.
Translator development
The Interlayer translator is the software direction behind our integration work: interpret a source message, apply an agreed mapping, and produce the representation required by a receiving system.
Identify the message type, required fields and source-system assumptions.
Apply explicit mappings and agreed checks. Report missing or incompatible values rather than silently inventing information.
Produce a target representation and document the transformation for review.
Illustrative example
This manually prepared example uses synthetic data to explain a possible mapping. It is not output from a live translator, an ISO 20022 message, or a claim of standards conformity.
{
"instruction_id": "DEMO-001",
"amount": "125.00",
"currency": "GBP",
"recipient_reference": "TEST-RECIPIENT"
}{
"payment": {
"reference": "DEMO-001",
"instructed_amount": {
"value": "125.00",
"currency": "GBP"
},
"recipient": "TEST-RECIPIENT"
}
}The example renames and groups fields while retaining their values. A real integration also needs schema definitions, business rules, validation, exception handling and agreed message versions.
ISO 20022-related work must identify specific message definitions and versions. JSON is a representation format; a JSON payload alone does not establish ISO 20022 conformity.
Any engagement-specific JSON representation must have a documented schema and mapping.
The deployment model is agreed for each engagement. Access, logging, retention and operational responsibilities must be defined for any environment that processes message data.
Operating principles →