elnyry-sam-k
commented
3 years ago This was discussed during the DA meeting on the 19th of August.
The group agreed that there needs to be a balance between the need to eliminate reconciliation and liquidity management of (Payer) FSPs by not holding/reserving funds for longer than necessary. In addition, It was proposed to use 'grace time period' before timing out transfers to compensate for differences in clocks. It was also suggested that for risky transactions, the final notification in the form of a PATCH call that was introduced with FSPIOP API v1.1 can be used to mitigate risk to the Payee FSPs.
One point made was that after the timeout period (plus the grace period to account for clock difference), a transfer status cannot be changed - it is either finalized or it isn't, but it cannot be changed. For example, if a timeout period (expressed as a time in future and not duration) is 10 seconds, then a Payer FSP (or Switch), may add a grace period of 1second and after waiting for 11seconds can query the downstream entity to find the transfer's status; At this point, if a transfer is finalized (Committed or Aborted), then the Payer FSP can take action accordingly; however if it is in an intermediate state, then the transfer has to be timed-out since the time-out period is done.
The group agreed on the need to revisit the topic of implementing 'telescopic timeouts', which is not currently supported in favor of end-to-end encryption of (most) messages.
godfreykutumela
MichaelJBRichards
Request:
At present, the switch is responsible for timing a transfer out. We therefore ask the payer DFSP to issue a GET /transfers before timing out at their end, to ensure that they only time transfers out if the switch has timed them out first. However, it is still possible for the switch to time a transfer out while the payee DFSP is still responding to it; and, given that the payee DFSP may clear funds to the payee account immediately and without waiting for confirmation from the switch, it is possible that funds may be disbursed to the customer by the payee DFSP without those funds being guaranteed by the switch's settlement records.
We should, perhaps, ask the switch to issue a GET /transfers to the payee DFSP before timing out. If a timely response is not received, or if the payee wants to abort the transfer, then the switch can go ahead and time it out. This articulates a general principle: an upstream participant should not time a transfer out without first seeking approval from the next downstream party.
This idea is also based around the proposal that the function of timing out is to ensure that transfers aren't left in limbo if one of the parties goes offline. Timing out is not, according to this idea, a way of ensuring that parties adhere to their response SLAs.
Artifacts:
Decision(s):
Follow-up:
Dependencies:
Accountability:
Notes: