Anticipating migration to newer version of pain.001 by incorporating some of the changes in old pain.001

For an FI which is using pain.001.001.03 and is expecting to update to a newer version of pain.001, e.g. to version pain.001.001.09, what types of changes will there be in the message, how big will the impact be for the customers and is there something the bank could do already in version 3, before initiating the full migration?

We covered some of the changes between old and new pain.001 versions in an earlier blog post. In this post we are going to focus on whether an old pain.001 could be updated to adhere with new ISO 20022 rules. In other words, we’ll investigate ways to anticipate migration to a newer version by incorporating some of the changes present in a new version by implementing them to pain.001.001.03.

The outcome of the investigation is that some changes can be done and make sense to incorporate, but understandably not everything can be included due to schema restrictions.

Possible changes to consider making to pain.001.001.03 to anticipate migration to new version

Postal Address

Upcoming changes to Postal Address elements can already be prepared in an older ISO 20022 version by moving away from using AdrLine element into using structured elements, such as StrtNm, BldgNb, PstCd, TwnNm.

However, it is worth noting that a new ISO version supports additional structured Postal Address elements not present in pain.001 version 3, which means that without using AdrLine in pain.001.001.03, it wouldn't be possible to include data such as as Floor, PostBox, Room and DistrictName.

Contact Details

Similarly to Postal Address, Contact Details in a new ISO 20022 version will have more structured elements supported. Additionally, element of 'CtctDtls/Othr' is defined differently in a newer version, which means moving away from the old usage of unstructured element usage can be a good idea.

In new version, element ChannelType is described as “Method used to contact the financial institution's contact for the specific tax region.”, which means that unstructured usage of ‘Other’ requires a 4 character code describing the content of the element ‘Identification’.

In many cases, this change is less important than the one affecting PostalAddress, since contact details and especially ContactDetails/Other is not used as much as PostalAddress/AddressLine.

External Code Lists

Due to the nature on how external code lists are defined, that they are not restricted by the schema itself, new codes introduced by ISO 20022 can be used any pain.001 message regardless of its version.

Differences in Business rules / Constraints

Newer ISO 20022 versions have more constraints which are not present in version 3 of the implementation, which may be easy to miss since they are not defined by the schema, but are defined in a textual format in the message documentation (MDR) instead. Here are additional ISO 20022 definitions of constraints which could already be adhered in version 3.

• ChequeFromGuideline
  CreditTransferTransactionInformation/ChequeInstruction/ChequeFrom may only be present if different from CreditTransferTransactionInformation/UltimateDebtor or Debtor.
  
  In other words, this means that ChequeFrom may not be used if it contains the same data as Debtor. Reasoning behind the rule is to avoid duplicate and thus confusing data being sent in cases where their contents are the same.
  
• ChequeInstructionDeliverToCreditorGuideline
  If PaymentInformation/CreditTransferTransactionInformation/ChequeInstruction/DeliveryMethod is present and is CRCD (CourierToCreditor), MLCD (MailToCreditor), PUCD (PickUpByCreditor) or RGCD (RegisteredMailToCreditor), then CreditTransferTransactionInformation/ChequeInstruction/DeliverTo may only be present if different from CreditTransferTransactionInformation/Creditor.
  
  This is a complex sounding rule, and in this case as well the reasoning is to avoid unnecessary duplicate data being sent. DeliverTo may only be present if its contents differ from Creditor, in cases when DeliveryMethod codes indicate deliveries to Creditor.
• ChequeInstructionDeliverToDebtorGuideline
  If CreditTransferTransactionInformation/ChequeInstruction/DeliveryMethod is present and if CreditTransferTransactionInformation/ChequeInstruction/DeliveryMethod/Code is CRDB (CourierToDebtor), MLDB (MailToDebtor), PUDB (PickUpByDebtor) or RGDB (RegisteredMailToDebtor), then CreditTransferTransactionInformation/ChequeInstruction/DeliverTo may only be present if different from Debtor.
  
  This is the same as above, but with Debtor instead of Creditor. DeliverTo may only be present if its contents differ from Debtor, in cases when DeliveryMethod codes indicate deliveries to Debtor.
• UltimateCreditorGuideline
  UltimateCreditor may only be present if different from Creditor.
  
  Here as well the reasoning is to avoid duplicate content. There is no need to specifically state the scenario where UltimateCreditor is the same as Creditor.
  
  
• UltimateDebtorGuideline
  UltimateDebtor may only be present if different from Debtor.

Changes in a new version which cannot be prepared in pain.001.001.03

There are plenty of changes between the versions which cannot be incorporated in pain.001.001.03. These are:

• Namespace, as it defines the version of the message and must match the schema used

• Difference in the way ReqdExctnDt is defined. This is a mandatory element and newer versions expect children element Dt or DtTm

  • Benefit of the new version is to optionally define the time more accurately, by using DtTm element, which allows the usage of exact time as opposed to only date.

• Difference in the way how RltdRmtInf is defined. Newer versions contain element RmtLctnDtls which is used as a parent for Mtd and ElctrncAdr

  • Since RmtLctnDtls is defined to be unbounded, the new version supports multiple addresses to be paired with one RmtId

• Additional supported elements, for which there is no room in pain.001.001.03. Examples of these are:

  • InitnSrc

    • This allows defining the source application or software used to initiate the payment.

  • for Agent elements, element LEI

    • ISO 20022 defines this as “Legal entity identification as an alternate identification for a party.”

  • MndtRltdInf

    • Provides further details of the mandate signed between the creditor and the debtor.

  • For ChqInstr, element Sgntr

    • Signature to be used by the cheque servicer on a specific cheque to be printed.

  • In RmtInf/Strd, element TaxRmt

    • Provides remittance information about a payment made for tax-related purposes.

  • In RmtInf/Strd, element GrnshmtRmt

    • Provides remittance information about a payment for garnishment-related purposes.