Change Request: Possibility to notify Payee FSP on successful commit in Switch about mojaloop-specification HOT 12 CLOSED

Aligned and Support to have this implementation with PATCH /transfers/ notification

from mojaloop-specification.

I support this change. This is an elegant way to conduct and track the progressive state change for selected use cases.

I would suggest, however, looking at the state labels that are used in the normal case:

In the bilateral arrangement, PUT COMMITTED (as written in the spec) makes sense since the payee commits the transfer in its own books.

However, when the optional switch is present, it would be more accurate to have payee PUT “FULFILLED” since only the switch can COMMIT the transfer for settlement. This indicates the unstable state of the transfer— payee has already paid out (I.e. fulfilled) when requesting clearing of the transfer. Next state entered by the switch is either COMMITTED or ABORTED.

from mojaloop-specification.

A gentle reminder to all assignees regarding review of this change request..

from mojaloop-specification.

from mojaloop-specification.

Thanks Miller,

I fully understand your view on fulfilled vs committed, but in the FSP's view the transfer is committed in their system so I don't see it as incorrect as it is now. The description of the possible transfer states in Figure 55 is also saying "Next ledger successfully performed the transfer", as such the state only represents the local ledger's state, not the switch ledger's state of the transfer. Using state FULFILLED would require a new major version of the API, as that state does not exist in the current major version (1).

from mojaloop-specification.

from mojaloop-specification.

Thanks for the additional information.

The transfer is committed in at least our system, we don't discern based on if it's a bilateral or switch-based scheme. If there would be a problem later with a transfer, it can be manually handled (e.g. refunded or reversed) by customer care, similar to other internal transactions. There is no difference in this between a bilateral or switch-based transfer in our system, both of them can be manually handled if there is a need for it.

The issue becomes clear when the payee DFSP asks the switch what the state of a transfer is. If the switch says it is committed, that means it is scheduled for settlement and the transfer is final. But if the transfer has not yet been committed within the switch, what state will the switch report to the payee DFSP?

What is said in the specification is that the switch should only return the finalized (terminal) state. It should wait with sending the callback to the FSP until it knows the finalized state. Excerpt from Section 6.7.1.6:
"If the GET /transfers/<ID> is received by the Switch after PUT /transfers/<ID> from the Payee FSP, but before clearing has completed, the Switch should wait with sending the callback until clearing has completed with either a successful or unsuccessful result. If clearing has already occurred (as shown in Figure 53), the PUT /transfers/<ID> callback can be sent immediately."

We can take this up separately as it does not have any impact to the CR on this thread. Perhaps we should separate this to a separate issue?

Sounds great, let's discuss further in a separate issue.

from mojaloop-specification.

A note to not forget about backward compatibility when this change comes ready for implementation.

Assuming this change becomes part of an API spec version iteration, there is a need to allow DFSPs on the existing v1.0 version of the spec to co-exist with switch and other DFSPs who support the new model. This comes back to the points raised during the Jan 2020 Johannesburg convening about API versioning, upgrade path and backward compatibility.

from mojaloop-specification.

@bushjames thanks. This (backward compatibility) has been (and will be) one of the primary considerations regarding this.

from mojaloop-specification.

This is now included in the Mojaloop FSP Interoperability API v1.1.

Before closing I had a question - can this be applied to bulk transfers as well? If so, at bulk level or individual transfer level, will raise it in the next CCB meeting.

from mojaloop-specification.

@elnyry-sam-k:

Before closing I had a question - can this be applied to bulk transfers as well? If so, at bulk level or individual transfer level, will raise it in the next CCB meeting.

No, not without major changes to the API. The BulkTransferState does not have a similar RESERVED state, and the IndividualTransferResult does not contain a state (they are either fulfilled or rejected).

from mojaloop-specification.

Ok, thanks @ehenrka

from mojaloop-specification.