Guideline No. | CR001 |
Purpose | To clarify the mechanics of an FIU placing a consent request for a citizen (natural person) that has not yet registered with an AA |
Description | New-to-AA citizens will either choose an AA or be presented with a recommendation by an FIU.
Once such a citizen chooses the AA he/she wishes to use, the FIU may send a consent request to that AA, using the “Mobile Number@AA_Identifier” in the “Customer Identifier” attribute of the consent request. This guideline is anchored on the principle that a citizen, wishing to use an AA service, is in possession of a mobile device and an active SIM card. |
Stage | Finalised |
Guideline No. | CR002 |
Purpose | To clarify the mechanics of an FIU placing a consent request for a corporate entity that has not yet registered with an AA |
Description | In place of the mobile number as an identifier for the entity seeking the VUA, an alternative that works well for legal entities such as companies has to be determined.
One can anchor this too on the principle that a corporate citizen, wishing to use an AA service, must be in possession of a PAN. The same attribute MUST then be part of the corporate citizen VUA issuance (registration) workflow of every AA. This is to be discussed further in the ecosystem. |
Stage | Under deliberation |
Guideline No. | CR003 |
Purpose | To clarify if a request can be placed for an irrevocable consent, by an FIU |
Description | There is currently no scope for a consent artefact to be deemed “irrevocable”. Consequently, there is no scope for a consent request to be placed, with the additional constraint that consent once given, should be irrevocable.
It is understood that there may be adverse consequences in terms of service availability from an FIU, if the consent provided to that FIU is revoked. The same is expected to be dealt with separately between the FIU and the FIU’s customer. All consent requests placed in the AA ecosystem are deemed revocable. |
Stage | Finalised |
Guideline No. | CR004 |
Purpose | To clarify what the max period of “data storage” is for an FIU and the difference between “Data Life” and “Data Storage” |
Description | The consent request placed by an FIU includes a parameter called Data Life. This represents the period that the FIU may “process” the data, once consented to, by the citizen.
This is however different from the “Data storage” policy that the FIU has. This policy stems from existing regulations and defines the maximum period that the FIU is expected to keep the data, to aid in any queries, grievances or disputes that may arise later, much beyond the period for which the data is being processed. The AA guidelines do not, in any manner, influence existing data storage policies. |
Stage | Finalised |
Guideline No. | CR005 |
Purpose | To clarify what “INF” stands for, in the parameters for Data Life and Frequency, in a consent request |
Description | INF – is inferred to be short for “INFinite”, or “Undefined”. It is not good practice to use this for either of the two attributes – Data Life and or Frequency. |
Stage | Under deliberation |
Guideline No. | CR006 |
Purpose | To clarify what “Consent Mode – Query” stands for and whether data-filter feature is implemented in the AA ecosystem |
Description | The QUERY permission allows additional filtering criteria to be included in the consent artefact. This allows the FIP to preprocess the data before responding to the request. The QUERY filter parameters may be defined by the FIP.
As of August 2022, this feature is not currently implemented in the AA ecosystem. However, this needs to be discussed further and implemented. |
Stage | Under deliberation |
Guideline No. | CR007 |
Purpose | To clarify what “Consent Mode – Stream” stands for and whether data-filter feature is implemented in the AA ecosystem |
Description | The STREAM permission facilitates in-point streaming of information to the FIU.
As of August 2022, this feature is not currently implemented in the AA ecosystem. However, this needs to be discussed further and implemented. |
Stage | Under Deliberation |
Guideline No. | CR008 |
Purpose | To clarify means to resolve inconsistencies in ENUM values in the specification, e.g TERM-DEPOSIT or TERM_DEPOSIT |
Description | A list of such inconsistencies and a decision as to which one to use has to be used.
TERM-DEPOSIT (e.g.) |
Stage | Under Deliberation |
Guideline No. | CR009 |
Purpose | To clarify what the term “FI Data Range” represents, for a use case that needs a look-ahead data-fetch (i.e data fetches in the future) |
Description | If the purpose of seeking consent is to process data for a time-period into the future (e.g. a personal finance use case), the FI Data Range represents the entire range of time for which data is expected to be fetched.
E.g. If on August 1st 2022, the consent is being sought, for data to be fetched for 6 months prior and till 12 months into the future, the FI Data Range will be “From Jan 1st 2022” and “To July 31st 2023”. |
Stage | Finalised |
Guideline No. | CR010 |
Purpose | To clarify how “Unit and Value” need to be interpreted, for Data Life and Frequency attributes |
Description | A unit of “1” and Value of “Month” is to be interpreted as “Once a Month”.
A unit of “2” and Value of “Day” is to be interpreted as “Twice a day”. The computation of time-units is to follow “Calendar” time, i.e. a day is to be deemed as starting 12 midnight, an hour is to be defined as per the system clock, a month is to be defined as per the system calendar. Thus, if “Twice an hour” is the frequency for which consent is provided at 10:30 AM, it implies “two times” in each hour, starting 10-11 AM, 11-12 Noon and so on. This interpretation is true for both Data Life and Frequency attributes. |
Stage | Under deliberation |
Guideline No. | CR011 |
Purpose | To clarify if any consent request parameter can be modified by the citizen, on the AA interface, prior to approving the same |
Description | Modifying one or more parameters in the consent request may adversely affect the ability of the citizen to avail herself of the financial service from the FIU.
It is therefore best for the AA to enable a simple “Reject” option, which the citizen can exercise in case he/she does not agree to any parameter value in the consent request placed. The FIU is then expected to send a fresh, corrected consent request. The interaction between the FIU and the customer, to do so, is outside of the purview of the AA’s role. |
Stage | Finalised |
Guideline No. | CR012 |
Purpose | To clarify the guideline for the maximum past duration for which transaction history is made available by FIPs |
Description | FIPs are expected to provide the same duration of transaction history as is currently available to a citizen via other digital channels – such as net banking or mobile banking.
In case different digital channels offer a different duration currently, the maximum available duration is to be taken as a benchmark for a citizen to avail of, via an AA as well. This is to be discussed within the community. |
Stage | Under Deliberation |
Guideline No. | CR013 |
Purpose | To clarify norms for how consent request attributes should be presented on AA Client interfaces to citizens |
Description | RBI Master Directions direct AAs as follows:
6.5 At the time of obtaining consent, the Account Aggregator shall inform the customer of all necessary attributes to be contained in the consent artefact as per paragraph 6.3 above and the right of the customer to file complaints with relevant authorities in case of non-redressal of grievances. The “inform customer of all necessary attributes” is to be implemented on AA client (web app, mobile app, e.g.) screens in a manner which neither overwhelms the citizen nor makes it incomprehensible. The community has devised a draft set of norms which have to be Finalised. |
Stage | Under deliberation |