Change Request: Support for ISO 20022 messages
mjbrichards opened this issue · comments
Open API for FSP Interoperability - Change Request
Table of Contents
1. Preface
___This section contains basic information regarding the change request.
1.1 Change Request Information
| Requested By | Michael Richards, ModusBox |
| Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ |
| Approved/Rejected Date | |
1.2 Document Version Information
| Version | Date | Author | Change Description |
|---|---|---|---|
| 1.0 | 2021-03-08 | Michael Richards | Initial version of template. Sent out for review. |
2. Problem Description
___2.1 Background
There have been a number of requests in the past to extend the Mojaloop system to support messages in ISO 20022 format. This requirement has now become urgent, to meet the needs of the proposed implementation in Rwanda. This change request discusses the changes that might be required to meet this need.
I want to look at the FSPIOP API from two slightly different perspectives. The first perspective is the endpoints that it supports; and, in particular, the endpoints that relate to the progress of a transfer. As we know, these fall into three phases: discovery, agreement and the transfer itself. Each of those phases has two messages associated with it: the original request, and a response (which can be either positive or negative.) Mojaloop works via requests and responses on the same resource type, whereas ISO 20022 typically has two different message definitions, one for the request and the other for the response. Otherwise, however, initial analysis of the ISO 20022 message catalogues suggests that There are ISO 20022 messages to support the following resources:
- /parties (query and callback)
- /participants (creation and callback)
- /quotes (creation and callback)
- /transfers (creation and callback)
- /transferRequests (creation and callback)
- /transactions (query and callback)
ISO20022 does not, in general, have a different syntax for bulk messages. The simple transfer is simply a specialisation of a bulk transfer. We may therefore omit the /bulkquotes and /bulktransfers resources. The only Mojaloop resource which is not covered by an obvious ISO 20022 message type is the /authorizations resource. We defer consideration of this for the initial implementation (actually, I think we defer it to a PISP discussion).
Our conclusion is that the orchestration aspect of the current Mojaloop API can be retained in an ISO 20022 context.
The second perspective is that of the content of the messages. It seems to me that there are two questions we need to answer here. The first is: will the content of the ISO 20022 message catalogue provide the content which the switch processes need to perform their functions? My answer to that is, broadly speaking, yes. I say "broadly speaking" to leave open the possibility that a scheme might want to evaluate rules based on information about the proposed transfer that an ISO message might not be able to contain. This seems to me, however, to be a relatively remote possibility.
The second question is: do the current Mojaloop messages contain information which cannot be encoded in the existing ISO 20022 structures? There are some cases where this is true: for instance, the complicated structure which is used to describe a transaction type is not directly representable in ISO. There are, however, other ways of representing a transaction's type. The most obvious problem, however, is the condition and fulfilment. There is no field in the existing ISO 20022 structures which represents these fields, and they are essential to the correct functioning of a Mojaloop system. However, ISO messages generally have a structure (the Supplementary Data field) which can be used to represent any information which cannot be represented in the existing ISO data structures; so my conclusion is that we can represent all the data we need to in the ISO structures.
Since this is the case, I propose that we should look at how to add support for ISO 20022 messages to the Mojaloop system. I think that the easiest way of doing this would be to set up a new API to manage interactions with the switch using ISO 20022, but would like to propose the question for discussion.
2.2 Current Behaviour
There is no current support for ISO 20022 messages
2.3 Requested Behaviour
N/A
It should be possible to define an ISO 20022 binding of the logical API introduced in Generic Transaction Patterns and Logical Data Model documents, similar to how the API Definition document defines an asynchronous RESTish binding of the logical API. As a side note, those documents should have some minor updates for version 1.1 so that they are fully aligned..
Maybe setup a subgroup of the FSP Interoperability API SIG that defines the ISO 20022 binding of the logical API?
In general, this is a good direction, but it is not really possible today. ISO 20022 is not a “protocol” — it is a message schema from which specific conforming messages are defined. There is no API defined. A large NGO, e.g., define SFTP as their protocol for payments interconnection. :-( Post an XML-formatted payment file to an SFTP server and hope you get an answer in a domain-specific format (likely a PDF report or CSV file) through a separate integration. So we ought to explore the separation of our API & protocol from the transaction messaging details. Do you believe our Generic Transaction Patterns and Logical Data Model accomplish this? Could we carry ISO’022 messages over our GTP? The mapping of our data model, as Michael says, is not really 1:1. Some information we need to exchange isn’t accommodated directly by the ‘022 schema, even if we accept the scope, domain, and range differences in the ISO spec. We would still be laying some of our info into supplementary data fields. But more importantly, ‘022 lacks messages for ALS as part of the PACS suite: there’s no way to ask a clearing system to resolve an alias to a participant ID (or IBAN prefix). I agree with you in principle, a mapping of our concepts onto an ‘022 base might be a good approach. We would at least learn the limitations of this approach. I do think involving banks and platform providers who use ISO 20022 natively would get us the best outcome. That’s the work Adrian is setting up with the ISO Real Time Payments working group, which is managed by SWIFT. — Miller On Mar 8, 2021, at 11:10 PM, Henrik Karlsson notifications@github.com wrote: It should be possible to define an ISO 20022 binding of the logical API introduced in Generic Transaction Patterns and Logical Data Model documents, similar to how the API Definition document defines an asynchronous RESTish binding of the logical API. As a side note, those documents should have some minor updates for version 1.1 so that they are fully aligned.. Maybe setup a subgroup of the FSP Interoperability API SIG that defines the ISO 20022 binding of the logical API? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#81 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6OJ6GISZKVBYLZ4WA65UDTCXCU3ANCNFSM4YZ3EAQA.
It's true, Miller, that the PACS suite doesn't contain analogues for ALS; but ISO does contain such messages. I've been doing some work with the guys from SADC, and we were proposing to use acmt.023 and acmt.024 from the payments maintenance message group. Rwanda, on the other hand, use camt.003 and camt.004 from the cash management message group. Either pair gives us the content we want, and can include the payee DFSP if required.
We also propose to use pain.013, which is a draft message from the RTP group representing a request to pay, as the analogue to PUT /quotes. So the two-phase commit now goes:
- pain.001 for POST /quotes (initiate a payment sequence)
- pain.013 for PUT /quotes (request to pay)
- pacs.008 for POST /transfers (execute the payment)
- pain.002 for PUT /transfers (payment status)
We figure to include the fulfilment and condition in the supplementary data; SADC are of the opinion that this should be doable. I've asked Misganaye to set up a meeting for us to look at this in a bit more detail.