<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4138537&amp;fmt=gif">
Menu
GET A DEMO


ISO 20022 doesn't
have to be XML

 
 

ISO 20022 is a business vocabulary. You can find lots of JSON APIs that use the ISO 20022 business vocabulary.


LEI is an important
new element in
ISO 20022 2019 version

 
 
LEI stands for Legal Entity Identifier. It is a globally unique alphanumeric reference based on the ISO 17442 standard assigned to a legal entity and maintained by GLEIF


camt.053 can replace
BAI2 and MT940
bank statements

 
 
camt.053 is the ISO 20022 format that can replace BAI2 and MT940 bank account statements. camt.052 and camt.054 can also be useful.


ISO 20022 isn't
limited to
payments 

 

It covers securities, trade services, cards, and more.


ISO 20022 allows for
both structured
and unstructured
remittance information

 
This flexibility aids in providing detailed payment references, enhancing reconciliation processes.


ISO 20022
accommodates both
batch and
real-time processing

 
The standard's flexible design supports various processing modes, enabling institutions to handle transactions in batches or individually in real-time, depending on their operational requirements.


The way banks use
the PmtTpInf element
varies wildly

 
 
PmtTpInfo stands for Payment Type Information and identifies the payment type. Usage varies a lot between banks.


Ustrd RmtInf might
be easy to use, but may
not be helpful for the
recipient

  
Ustrd RmtInf stands for Unstructured Remittance. If the remittance text is hard to parse, then automatic payment reconciliation becomes difficult and unreliable.


The allowed length of
string elements varies
a lot across banks

 
 
The length of individual data fields that a bank can process in its payment systems varies a lot. As a result, many string elements in ISO 20022 gets truncated when processed by the bank.


Flat files include a very
limited amount of data.
That makes them simpler

Flat files include a very limited amount of data. That makes them simpler - but also less useful for automated reconciliation, fraud checking, etc.


Structured addresses
result in a lot less false
positives for fraud and
sanctions screening

  
Structured addresses result in a lot less false positives for fraud and sanctions screening. If "Cuba Street" is included in an unstructured address it may trigger a false positive. If the same is included in a structured address street field, it will not.

CBPR+ is for cross
border, HVPS+ is for
high value payments
systems

  
CBPR+ is for cross border, HVPS+ is for High value payments systems. Read more

Eager to discover more? Check out our knowledge base.

Are You ISO 20022 whisper? Send it to us!