| Guideline No. | DR001 |
| Purpose | To clarify what the session time-out values are, for session IDs issued by either AAs (to FIUs) or by FIPs (to AAs) |
| Description | Session IDs issued by AAs or FIPs have a time-out value. This value represents the maximum time that the AA or the FIP may take to service the data request received.
60 minutes is the value that AAs / FIPs are expected to configure as the session time-out value. This implies that FIUs or AAs may expect a notification pertaining to their data request anytime within a maximum of 60 min. If no notification is received within this period, it would essentially mean that the request has “Failed” and a fresh request needs to be initiated. |
| Stage | Under deliberation |
| Guideline No. | DR002 |
| Purpose | To clarify if retries are allowed by AAs (for FIUs) and by FIPs (for AAs) for failed sessions |
| Description | Once a citizen gives consent, he/she expects the participants to ensure that data is shared amongst them, as per the consent parameters.
This implies that FIPs and AAs are expected, by the citizen, to take appropriate corrective measures, if there are technical reasons (and not business reasons) for a data request to be declined. Hence, FIPs and AAs are expected to enable AAs/FIUs (respectively) to “Retry” a data-request, if a previous one fails, i.e. the session state returned for that is “failed” or no notification is received within the session ID time-out value (as defined in DR001). The number of retries is expected to be capped to a number being discussed in the ecosystem. |
| Stage | Under deliberation |
| Guideline No. | DR003 |
| Purpose | To clarify the meanings and behaviours associated with session Status and FI Status values |
| Description | The meanings and behaviours of these two attributes – Session Status, FI Status – are as per the community guidelines documented here:
https://github.com/Sahamati/certification-framework/blob/main/guidelines/session-id-and-fi-status-states.md |
| Stage | Finalised |
| Guideline No. | DR004 |
| Purpose | To clarify if a “partial fetch” of data is allowed for an FIU, from an AA, in the event the citizen consents to provide data across multiple accounts, either from one FIP or multiple FIPs |
| Description | There are financial use cases that offer value to a citizen, even with data partially available, in the event there are technical or business declines for some of the data that the citizen has consented to give.
AAs and consequently FIPs have to honour delivery of such “partially” available data. The mechanics of “partial data delivery” have to be first implemented by FIPs and then by AAs. This is currently under discussion. |
| Stage | Under Deliberation |
