| Guideline No. | RC001 |
| Purpose | To clarify if the type “INF” can be used as a parameter to denote “undefined / adhoc / infinite” frequency, while seeking recurrent consent |
| Description | While INF is provided for as one of the valid values, and it is inferred to be short for “INFinite”, it is considered to be NOT a good practice to use this, to denote recurring consent frequency.This would effectively imply no limit on the frequency of pulls and is not useful from the perspective of citizens’ privacy.It is advised therefore that only one of the other values for frequency – which denote a specific recurrence pattern – be used and not INF. |
| Stage | Under Deliberation |
| Guideline No. | RC002 |
| Purpose | To clarify if different consent parameters (such as frequency, date range) can be applied to different financial information types, using a single consent |
| Description | The current specifications (V 1.1.2) do not allow for consent parameters to be different for each FI type sought in the consent request, by the FIU.Hence, if an FIU seeks three FI types (e.g. deposit, insurance, MF), the consent parameters have to be designed such that they apply for all FI types.It is understood that this may not work for use cases where recurrence may be required at a higher frequency for one FI type (e.g. deposit) but not for the other (e.g. insurance).
This needs to be discussed within the community to evolve a change request. |
| Stage | Under deliberation |
| Guideline No. | RC003 |
| Purpose | To clarify if consent can be taken for an indefinite/long period (e.g. multiple years) if the financial service tenure is similarly indefinite or long (e.g. PFM or loan monitoring purposes) |
| Description | From the citizens’ perspective, protecting the citizen against inadvertent sharing of the citizens’ data is primary.In the case of a recurring consent with a long-term validity, the risk of the user “forgetting” that such consent has been given has to be factored in as a problem to be solved.As a basic guideline, it is advised that consent validity durations be restricted to 1-2 years, with the understanding that citizens may be able to “extend” the same periodically.
The mechanics of this are currently being discussed in the community. |
| Stage | Under Deliberation |
| Guideline No. | RC004 |
| Purpose | To clarify if there are maximum limits defined for consent frequency |
| Description | It is necessary to ensure that a key requirement of data privacy is kept in mind, during implementations
One way of enforcing this is to define guidelines for maximum frequency limits, for typical use cases. This is under discussion in the community. |
| Stage | Under Deliberation |
| Guideline No. | CDR001 |
| Purpose | To clarify if a citizen can be a recipient of his/her own data via an AA |
| Description | As per the RBI Master Directions, an AA’s charter is to enable (amongst other things) presentation of a citizen’s data to herself.Given that an AA is data-blind, this implies that an AA service can deliver encrypted data to the device owned by a citizen.Further, to enable presentation of data received by the device, an AA client (front-end application) that is resident on the device of the citizen (such as a mobile app) may offer the feature of decrypting and presenting data.
Under no circumstances is the decrypted data allowed to be stored on the servers of the AA, since that is in contravention to the principle of the AA being data-blind. |
| Stage | Finalised |
| Guideline No. | CDR002 |
| Purpose | To clarify if the citizen’s access to her own data also is based on the structure of an electronic consent artefact |
| Description | All sharing of data via an FIP’s service is to be done on the basis of an electronic consent artefact, regardless of whether the recipient of data is an FIU (a registered/regulated entity) or the citizen herself.Hence, an AA must generate an electronic consent artefact even if the recipient of the data is the citizen herself and share the same with the citizen’s FIP.When the recipient is an FIU, a copy of the consent artefact is also shared with the FIU.
When the recipient is the citizen herself, it is left to the AA to determine if the citizen (i.e. the device owned by the citizen) gets a copy of the artefact approved by her or not. This is to be discussed within the community. |
| Stage | Under deliberation |
| Guideline No. | CDR003 |
| Purpose | To clarify if a citizen may share her data with any other party, on her own through an AA’s mobile app installed on her device |
| Description | An AA’s mobile app may decrypt data, once data has been delivered by the AA service to the device of the citizen.Such decrypted data may be presented to the citizen on the AA’s mobile app. It may also be shared by the citizen with any party of the citizen’s choice using commonly accepted digital methods – such as via email, whatsapp or any other sharing service that the citizen prefers.This feature is akin to what may be available to a citizen through the citizen’s own banking application, e.g.
This is to be discussed within the community. |
| Stage | Under Deliberation |
| Guideline No. | CDR004 |
| Purpose | To clarify if a citizen may share her data with any other party, on her own, through an AA-owned library embedded within the third-party app. |
| Description | In addition to the guideline described in CDR003 (which applies to even this scenario), an AA must also ensure its fiduciary duty towards the citizen is met, if and when the AA partners with a third-party to offer a deeply-embedded journey.Given that the charter of the AA is to enable either FIUs or the citizen’s device to be the destination of the citizen’s data, AAs are expected to serve only FIUs or the citizens with data-sharing capabilities.If an AA partners with an entity that is not an FIU (i.e. is not a registered and regulated entity) and enables convenience-mechanisms for citizens to share their data with such entities, does the AA have a fiduciary duty of ensuring safe-handling of data by such entities?
Can the AA discharge such a duty, even if it has one? This is to be discussed within the community. |
| Stage | Under deliberation |
