ISO 20022 User Interface Considerations: Purpose of Payment

COMING SOON... Many jurisdictions around the world require a purpose of payment code (PoP) or regulatory reporting information including in payment instructions.  Without them, the payment may be rejected. How then to build a UI, catering for the myriad complex rules whilst ensuring a seamless and simple customer experience.

PRE-READING:  PMPG ISO 20022 Market Practice Guidance – Regulatory Reporting, Purpose of Payment and Category Purpose

Aim

Many jurisdictions around the world require a purpose of payment code (PoP) or regulatory reporting information including in payment instructions.  Without them, the payment may be rejected.

ISO 20022 payment instructions, specifically the pain.001 and pacs.008, used for customer credit transfers, have specific data elements to carry this information. Populating it with the correct codes, in the correct use cases, for the correct destinations is not straightforward. For file or API based integrations, between a corporate and their bank or payment service provider, this data will come from the originating system, and we won’t cover this here.

For banking and payment applications, with a user interface, capturing this data, whilst not baffling the customer with complex scenarios and lists of codes, is a significant challenge. The aim is a seamless and simple customer payments journey.

In this article we’ll look at some of the challenges for capturing PoP codes (and Regulatory Reporting Information), some design options to consider, with a focus on keeping the customer experience streamlined and simple.  We’ll also briefly look at Category Purpose codes.

…to follow. Keep tuned in for the full article.

Leave a Reply

Your email address will not be published. Required fields are marked *