SWIFT MT & ISO 20022 Standards Compliance
Every SWIFT message your institution sends must comply with a dense set of rules: structure requirements (mandatory sequences, field ordering, repetitions), format rules (character sets, lengths, qualifiers), and semantic validations -- hundreds of network-level rules that define valid combinations of field values across each message category.
Building this in-house means reverse-engineering SWIFT's standards documentation and implementing hundreds of rules per message type. That alone can take 6-12 months of development. Then, every year, SWIFT publishes a new Standards Release Guide (SRG) -- adding rules, modifying existing ones, deprecating others -- and the cycle starts again.
With the migration to ISO 20022, the validation surface has expanded significantly. MX messages introduce XSD schema validation, cross-element rules, external code sets, and market-practice-specific usage guidelines like CBPR+. Maintaining compliance across both MT and MX -- especially during the coexistence period -- compounds the effort.
The cost of getting it wrong
Non-compliant messages are rejected by the SWIFT network. Rejected messages delay settlements, trigger manual repair cycles, and create operational risk -- especially for time-sensitive payments and confirmations.
Prowide's validation engine implements complete SWIFT network rules, tested in live production systems across 50+ countries. Instead of building and maintaining your own rule engine, you get a validated, up-to-date library that stays current with every SRG.
Scope: message standards, not financial crime screening
This solution validates messages against SWIFT and ISO 20022 standards -- structure, format, network rules, and reference data. It is not AML, sanctions, or PEP screening: Prowide does not maintain watchlists or run name-matching algorithms. What the Messaging Hub does provide is the workflow orchestration around your existing screening system -- calling it, holding messages until it responds, and routing on the outcome.
Structure Validation
Verifies mandatory sequences and fields are present, correctly ordered, and within allowed repetition limits. Detects missing blocks, invalid sequence nesting, and structural errors.
Format & Field Validation
Checks each field against its format specification -- mandatory components, allowed character sets, maximum lengths, valid qualifiers, and option letter constraints.
Semantic Rules
Applies the full set of SWIFT network validation rules -- cross-field dependencies, conditional requirements, and business logic constraints specific to each message type.
Reference Data
Validates BIC codes against the SWIFT BIC directory, verifies IBAN structure and check digits, checks SWIFTRef reference data, and confirms ISO country and currency codes are current and valid.
Usage Guidelines
For MX messages, validates against market practice usage guidelines -- CBPR+ schemas, regional clearing rules, and restricted code sets that go beyond base ISO 20022 schemas.
Custom Rules
Add your own institution-specific validation rules on top of the standard checks. Enforce internal policies, counterparty-specific requirements, or additional business constraints.
MT Message Validation
Full validation of all SWIFT MT message categories -- covering the complete set of format rules, semantic validations, and network rules that SWIFT applies at the network level.
MX Message Validation
Comprehensive ISO 20022 message validation -- from XSD schema compliance through cross-element rules and market-practice-specific usage guidelines.
ISO 20022 messages come with usage guidelines -- market-practice-specific restrictions layered on top of the base schemas. The most significant of these is CBPR+, the Cross-Border Payments and Reporting Plus specification that governs how ISO 20022 payment messages are used on the SWIFT network.
CBPR+ defines restricted message schemas, additional field-level rules, and standardized translation mappings between MT and MX. Prowide validates against the latest CBPR+ version, ensuring your MX payment messages comply before they reach the network.
Beyond CBPR+, regional clearings define their own MX usage guidelines -- each with specific schema restrictions, code set requirements, and field-level rules. Prowide supports validation for 15+ regional clearings so your messages comply with local requirements as well.
CBPR+ Payment Messages
Restricted schemas and usage rules for pacs.008, pacs.009, pacs.004, camt.056, and other CBPR+ message types.
Regional Clearing Guidelines
T2, LYNX, CHATS, RITS, MEPS+/SCRIPS, FISC, EBA, Fedwire, SIC, and more -- each with their own MX flavors and rules.
Translation Compliance
When translating between MT and MX, validation ensures the output message meets the target format's usage guidelines -- not just the base schema.
Intelligent Variant Detection
Automatic detection of which usage guideline applies to a given message, based on the message context and clearing destination.
SWIFT BIC Validation
BIC codes in your messages are validated against the SWIFT BIC directory. The BICImport tool enables loading SWIFT's directory file into the validation engine, keeping your BIC reference data current.
IBAN Structure & Check Digits
IBAN numbers are validated for correct country-specific structure, length, and check digit calculation -- catching common transcription errors before they reach the network.
Country & Currency Codes
ISO country codes and currency codes are verified against the current standard lists, flagging deprecated or invalid entries that would cause network rejection.
SWIFTRef Data Validation
Leverage all available SWIFTRef reference data for effective validation -- IBAN Plus, Participants, LEI, SSI, BIC Plus, and national ID directories. Ensures identifiers, routing codes, and institutional data match SWIFT's authoritative sources.
ISO 20022 Code Lists
For MX messages, external code set values are validated against the ISO 20022 maintained lists -- purpose codes, instruction codes, charge bearer codes, and other enumerated values.
In the Messaging Hub, validation is an action in the ECA workflow engine, not an afterthought. It runs on outbound messages before they reach the dispatcher and on inbound messages as they arrive, so a standards breach is caught at the point where it can still be corrected.
Messages that fail are held rather than delivered. Each is tagged with the rules it broke and the fields involved, then routed to a review queue in the operator GUI. Operators see the specific error descriptions -- not a generic failure -- and repair the message in place, with field-level validation guiding the correction.
Enforcement policy is configurable per message flow: block and queue for repair, or pass through with a warning where a downstream system owns the decision. Rule changes can be exercised with dry-run mode before they affect live traffic.
Every outcome -- pass, fail, repair, release -- lands in the message audit trail, under role-based permissions and 4-eyes authorization where you require it. That record is what turns "we validate our messages" into evidence you can show an auditor.
Validated before delivery
Outbound messages are checked before the dispatcher sends them -- a rejection avoided costs nothing, a rejection received costs a repair cycle and a delayed settlement.
Checked on arrival
Inbound messages are validated as they enter, so malformed counterparty traffic is identified before it reaches your back-office systems.
Held, not silently dropped
Failed messages stop in a review queue with their error detail attached. Nothing disappears, and nothing goes out un-validated.
Repaired by an operator
Guided repair in the UI with field-level validation, so the corrected message passes on resubmission instead of failing a second time.
Policy per flow
Choose block-and-queue or warn-and-continue per message flow, with dry-run testing before rules go live.
Auditable end to end
Validation results, repairs, and releases recorded in the message audit trail with role-based access and 4-eyes authorization.
Standards validation and financial crime screening answer different questions. Validation asks is this message well-formed and network-compliant? Screening asks is this party, country, or purpose permitted? The second question belongs to your AML or sanctions platform, which owns the watchlists, the name-matching logic, and the regulatory audit position.
What institutions typically lack is the connective tissue: something that intercepts each message at the right point in the flow, calls the screening system, parks the message until a verdict comes back, and then acts on that verdict without a human retyping anything. That orchestration is what the Messaging Hub provides.
Screening is configured as a step in the ECA (Event-Condition-Action) workflow engine, using the same condition filters as the rest of your routing -- BIC patterns, message types, currencies, amount ranges, and field-level matching. You decide which flows are screened, at what point, and what happens on a hit. Rules can be tested with dry-run mode before activation.
Because screening runs inside the Hub, the outcome lands in the same place as everything else: one message record, one audit trail, one operator inbox. There is no separate console to reconcile and no gap between "validated" and "screened" in your evidence.
Message reaches the screening step
ECA conditions select which messages are screened -- by direction, message type, counterparty BIC, currency, amount threshold, or any field-level criteria
External screening system is called
A Custom Action invokes your AML platform over REST, IBM MQ, RabbitMQ, or file exchange -- whichever interface the vendor exposes
Message is held pending the verdict
The message stops in the flow rather than continuing to the dispatcher -- nothing leaves the institution while screening is outstanding
Routing follows the outcome
Clear results continue automatically to delivery. Hits and inconclusive results are tagged and routed to a review queue in the operator GUI
Compliance officer decides
Release, reject, or repair from the Hub UI -- under role-based permissions and 4-eyes authorization, with every action recorded in the audit trail
Owns the screening decision
Owns the message workflow around it
SWIFT publishes a new Standards Release Guide (SRG) every year, typically with a November go-live date. Each SRG can add new semantic rules, modify existing validations, introduce new message types, update code sets, and change field requirements.
For institutions that maintain their own validation logic, each SRG triggers a development and testing cycle. With Prowide, the update is delivered as a library update -- new rules, modified validations, and updated reference data included, ready to deploy.
Prowide delivers SRG updates 6 months before the go-live date, giving your team ample time to integrate, test, and certify the new version in your environment before the changes take effect on the SWIFT network.
SWIFT publishes SRG specification
New rules, modified validations, updated code sets, and message changes are documented
Prowide implements and tests
Full rule implementation with regression testing across all message categories
Early release delivered (6 months ahead)
Updated library available for integration and testing in your environment
Your team integrates and certifies
Deploy the update through your standard change management process
SRG goes live on SWIFT network
Your validation engine is already current -- no last-minute updates or compliance gaps
50+
Countries running Prowide validation in production
MT & MX
Full coverage of both ISO 15022 and ISO 20022 standards
15+
Regional clearing usage guidelines supported
6 mo
SRG updates delivered before network go-live
Prowide Integrator
The Validation module is a Java library that you integrate into your own applications. Call the validation engine from your code, get structured results, and handle errors in your own way.
Prowide Messaging Hub
Validation runs automatically on every message flowing through the Hub -- outbound messages are validated before delivery, inbound messages are checked on arrival. Non-compliant messages are flagged for operator review.