Session ID and FI Status States

Standard definitions for Session ID and FI status states

Principles guiding the implementation of Session IDs and FI Status state machines

Unless otherwise mentioned,
The term “Network participant” refers to AA, FIP and FIU roles.
The term “Data Provider” refers to both the FIP and the AA roles.
The term “Data Consumer” refers to both the AA and the FIU roles.
In a FIP-AA interaction, the FIP is the Data Provider while the AA is the data consumer. In an AA-FIU interaction, the AA is the Data Provider while the FIU is the data consumer

All network participants will implement state machines (state names, transitions) that are consistent with the meanings defined below - for both Session ID states and FI Status states.
Data providers are free to choose which of the states trigger notifications to Data consumers. Further, if a Data Provider is expected to provide data across more than one account, the choice of notifying the Data Consumer on a piecemeal basis (i.e. as and when a particular account’s data is ready to be shared) VS on an aggregated basis (i.e.only after ALL the accounts’ data is ready) is left to the Data Provider.
Data consumers are advised to implement a defensive programming approach, with respect to their interpretation of how data providers send notifications. Specifically, data consumers are advised to independently verify whether a session is deemed “complete” (in terms of their having received all data expected) or not and not rely only on the data provider’s notification deeming a session as “complete”. This is because there could be race conditions in the network that disorient the sequence of receipt of notifications. An “active” session notification could potentially follow a “completed” session notification, in some cases, however infrequent they may be.
Data Providers have to deem their job as complete, only when ALL the data they are expected to provide has been either delivered or is denied for valid reasons. If even some of the data is unavailable, either for reasons of failure at their end or in downstream systems (a FIP is downstream to an AA, e.g.), the Data Provider should, in the best interest of the data consumer, deem its job as having failed.
Data Providers have to write code to honor repeat issuance of session IDs for previously failed sessions.

English Meanings of sessions initiated by “Data Providers” for “Data Consumers”

“Data Providers” (either FIPs or AA) “Data Consumers” (either AA or FIUs, respectively)

English Meanings of FI Status values

PreviousGeneral Guidelines NextAA

Last updated 2 years ago

Principles guiding the implementation of Session IDs and FI Status state machines

Unless otherwise mentioned,

The term “Network participant” refers to AA, FIP and FIU roles.
The term “Data Provider” refers to both the FIP and the AA roles.
The term “Data Consumer” refers to both the AA and the FIU roles.

In a FIP-AA interaction, the FIP is the Data Provider while the AA is the data consumer. In an AA-FIU interaction, the AA is the Data Provider while the FIU is the data consumer

All network participants will implement state machines (state names, transitions) that are consistent with the meanings defined below - for both Session ID states and FI Status states.

Data providers are free to choose which of the states trigger notifications to Data consumers. Further, if a Data Provider is expected to provide data across more than one account, the choice of notifying the Data Consumer on a piecemeal basis (i.e. as and when a particular account’s data is ready to be shared) VS on an aggregated basis (i.e.only after ALL the accounts’ data is ready) is left to the Data Provider.

Data consumers are advised to implement a defensive programming approach, with respect to their interpretation of how data providers send notifications. Specifically, data consumers are advised to independently verify whether a session is deemed “complete” (in terms of their having received all data expected) or not and not rely only on the data provider’s notification deeming a session as “complete”. This is because there could be race conditions in the network that disorient the sequence of receipt of notifications. An “active” session notification could potentially follow a “completed” session notification, in some cases, however infrequent they may be.

Data Providers have to deem their job as complete, only when ALL the data they are expected to provide has been either delivered or is denied for valid reasons. If even some of the data is unavailable, either for reasons of failure at their end or in downstream systems (a FIP is downstream to an AA, e.g.), the Data Provider should, in the best interest of the data consumer, deem its job as having failed.

Data Providers have to write code to honor repeat issuance of session IDs for previously failed sessions.

English Meanings of sessions initiated by “Data Providers” for “Data Consumers”

“Data Providers” (either FIPs or AA) “Data Consumers” (either AA or FIUs, respectively)