By Michael Richards
This article contains technical details about how Mojaloop works. If you’re new to the topic, you might want to start at https://mojaloop.io/how-it-works/.
Mojaloop is currently moving away from its existing practice of indeterminate definition of settlement windows to a process which deterministically assigns transfers to settlement batches based on time. This change will make reconciliation in jurisdictional systems much simpler, since participants should be able to synchronise their records with known contents of settlement batches; and it will be indispensable for cross-scheme implementations, since it will allow different schemes to compare directly comparable sets of transactions.
Deterministic assignment of transfers requires a single time to be assigned to the transfer, which will be identical across multiple clocks, both at DFSPs and at switches. The time assigned to a transfer will be the time which the payee DFSP attached to the transfer completion message when it confirmed the transfer; or the time at which the switch to which the payee DFSP is attached cancelled the transfer, if the transfer is cancelled by the switch.
This gives rise to a problem: There is no guarantee that the clocks at different payee DFSPs will agree on time with the switch with the precision required for deterministic assignment of transfers. This would not matter for assigning transfers to batches, except for one thing: there is no reliable way for a switch to tell whether or not it has received all the transfers which will eventually populate a given settlement batch. This is a significant design problem, since we need to be able to create summary totals for each batch, and we can only do that reliably if we can be confident that a batch is complete. This document proposes a solution to the problem.
How the Switch Works
When the switch to which the payee DFSP is attached receives a request to complete a transfer via the POST /transfers endpoint, the request will have an expiration time attached to it. This is taken by the switch to which the payee DFSP is attached as expressed in its own clock. The switch to which the payee DFSP is attached is the only switch capable of timing a transfer out in a multi-scheme payment, and will hereafter be referred to as “the switch”.
When the switch receives a request to execute a payment, it will reject that request if the expiration time has already passed. All transfers which pass for processing will therefore have an expiration time in the future, by the switch’s clock. The payment execution request will be persisted, and the set of these execution requests will be the set of open transfer requests. Each of these requests will have an expiration time attached, and the switch can be confident that the transfer will be finalized by that time, by being either completed, or rejected, or timed out. We might call these transfers candidates.
Segmenting Candidates by Batch
It may be efficient to segment these candidates by batch. This means that an incoming transfer will belong to the current batch; but it may also belong to one or more subsequent batches. Segmenting in this way will mean that we can maintain lists of the transfers which belong to each batch separately.
For instance, we suppose that batches are set to occur every 10 minutes. A transfer is received at 12:09, and it has an expiry time of 2 minutes. This transfer might eventually be allocated either to the 12:00 to 12:10 batch, or to the 12:10 to 12:20 batch, depending on when it is finalized. It should therefore be added initially both to the 12:00 to 12:10 batch and the 12:10 to 12:20 batch.
If we now add another transfer which has an expiry time of 12 minutes, it should be added to all three batches:
The duplication is not problematic as long as the transfer has not been finalized; when it is finalized, it should only be retained in the batch into which it is finalized, and the assignment to other settlement batches should be removed. So if the original transfer is finalized into the first batch we’ll have the following conditions:
The set of transfers which belong to a given settlement batch is therefore the set of transfer requests which were received after the start of the batch, as decided by the switch, and which were finalized before the end of the batch.
When the switch’s clock passes the end time of the batch, then no more transfers can be added to the batch. At that point, there will be a fixed list of open transfers (there may be finalized transfers which belong to the batch as well, but we are not interested in them for the purposes of this proposal). Some candidates may eventually be allocated to the batch in question, and some may be allocated to subsequent batches. The distribution between batches is unknown at that point; but what is known is that, when all the candidates are finalized, the settlement batch will be complete. At this point, we might think of changing the settlement batch’s status from OPEN to CLOSING.
Closing Batches
Now all we need to do is check until all the candidates for the CLOSING batch are finalized. We could do that each time a transfer completes, or via some batch process: it doesn’t really matter. But when all the candidates for a given batch are finalized, that batch is CLOSED. No more transfers can be added to it and, per the removal of transfers which are finalized to other batches, the batch contains a list of the transfers which have been finalized to it.
I think that this process will work for any switch in an interscheme without requiring any specialized processing for switches, other than the one that the payee DFSP is attached to (and ensuring that only that switch can time a transfer out.)
This method will be inefficient to the extent that it will delay the closure of a batch until some candidates which might have belonged to it are finalized into different batches; but it is not a requirement of this solution that batches should be available for settlement immediately, or in the shortest possible time, after they are put into CLOSING status. The delay in finally closing a batch is therefore expected to be tolerable in the context of overall system performance.
If you’re a member of the Mojaloop community, we’d welcome any comments or questions you might have on this proposal – especially any suggestions for improvement. If you’re not a member of the community, you can join here and we hope to hear from you.
