Change Request: Support for ISO 20022 messages about mojaloop-specification HOT 3 OPEN

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?

from mojaloop-specification.

from mojaloop-specification.

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 [email protected] 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:

1. pain.001 for POST /quotes (initiate a payment sequence)
2. pain.013 for PUT /quotes (request to pay)
3. pacs.008 for POST /transfers (execute the payment)
4. 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.

from mojaloop-specification.