Guideline No. FUR001
Purpose To clarify the definition of FIUs
Description As per RBI Master Directions, only entities that are both “Registered with and regulated by” one of the four financial sector regulators (RBI, SEBI, IRDAI, PFRDA) are eligible to be an FIU. 

Conversely, entities that do not carry a certificate of registration from any of the four financial sector regulators cannot participate as an FIU.

Further, it is implicitly understood that the use case/purpose that an FIU is seeking to process the citizen’s data for, is permitted as per the licence charter of the FIU.

It is the FIU’s responsibility to assure itself and the rest of the ecosystem of the permissibility of its use case/purpose.
Stage Finalised
 
Guideline No. FUR002
Purpose To clarify the fiduciary obligation of an FIU
Description The term “fiduciary obligation”, in the context of an AA, implies that an FIU has an obligation to prudently take care of the data principal’s data (the “asset”) and establish a relationship of trust. 

This also means that the FIU has an obligation to not profit from its fiduciary duty, without knowledge and consent of the data principal.

The direct implication of this, on an FIU’s behaviour, is:

  • To use the citizen’s data strictly in accordance with the consent artefact, provided by the citizen through an AA
  • To ensure that the citizen’s data is NOT employed for any other purpose, unless with the explicit knowledge and informed consent of the citizen. Such consent has to be taken in addition, if required, to what the citizen has provided for, through the AA.

The key question to be deliberated by the community: The FIU may not have a fiduciary relationship with a citizen, for the regular business that it is chartered to perform. E.g. an insurance web aggregator does not have a fiduciary relationship with an insured party, while an insurance broker has.

Both however can be FIUs since they are registered with a regulator.

Can an insurance web aggregator seek consent from citizens to procure data and discharge its fiduciary obligation towards safe-guarding data, although the larger context of what it offers citizens (a portal to discover offers) is not on the basis of a fiduciary relationship?
Stage Under deliberation
 
Guideline No. FUR003
Purpose To clarify if an FIU may have multiple entries in the central registry
Description An FIU may have multiple deployments of its FIU gateway, either to serve different departments within its FIU or as a technical redundancy measure. 

Each such gateway may have its own public IP, public keys.

In the current version of the central registry and token service, each such gateway will have its own entry, with its own unique FIU ID.
Stage Finalised
 
Guideline No. FUR004
Purpose To clarify if a holding company that is not a registered and regulated entity itself can be considered an FIU
Description Only entities that are directly “Registered with and regulated by” a financial sector regulator can be considered an FIU. 

Any other entity, including parent/holding companies of such an entity are not considered an FIU.
Stage Finalised
 
Guideline No. FUR005
Purpose To clarify if an FIU is obligated to integrate itself with all licensed AAs or not
Description Citizens should be free to choose which AA they set up a profile with. Once the choice is made, all FIUs ought to respect that choice and redirect their consent requests to the citizen’s AA. 

This implies two principles to guide FIU user journeys:

  • If a citizen is new-to-AA, i.e. does not declare h/she already has an AA profile, the FIU is free to recommend an AA that the citizen may register with.
  • If the citizen however indicates that h/she already has an AA profile, FIUs are obliged, as per community norms, to respect that choice and redirect the citizen to that AA.

It is further therefore necessary that FIUs find out if citizens already have an AA profile or not, to enable implementation of the above principles.

This is being discussed in the AA community.
Stage Under deliberation
 
Guideline No. FUR006
Purpose To clarify if FIUs can “discover” which AA a citizen already has a profile with, in order to direct citizens by default to their AA
Description AAs may offer a standard API that allows FIUs to verify if a citizen (identified through the mobile number) is already registered with them or not. 

This would enable FIUs to avoid asking the citizen to recollect his/her VUA or worse, enforce citizens re-registering with a different AA altogether.

This is currently being discussed within the AA community.
Stage Under deliberation
 
Guideline No. FUR007
Purpose To clarify if AA handles issued by AAs can include the brand-name of an FIU or not
Description FIUs play an important role in terms of encouraging citizens (their customers) to use AA. 

FIUs also partner with one or more preferred AAs, for new customer registrations, initiated in the course of their own digital journeys.

FIUs may be interested in ensuring AA handles issued, post-registration, include the brand name of the FIU. This serves as encouragement to FIUs to further use the “AA Handle” as a marketing tool to nudge further usage, within their own products and services.

This needs to be discussed further within the AA community.
Stage Under Deliberation
 

Back to AA Community Guidelines Summary