|Purpose||To clarify if auto-discovery, i.e. discovering a customer’s accounts held across FIPs without the customer explicitly indicating which FIPs, is allowed or not|
|Description||Auto-discovery enables convenience for customers and also functional benefits, particularly for purposes such as Wealth Management Service.
However, it generates a lot of unnecessary traffic and puts stress on FIP systems, if used without guardrails.
What should such guardrails be, if at all?
|Purpose||To clarify if discovery can be done on FIPs specified by the customer on the FIU interface, which is then subsequently passed to the AA via the FIU-AA integration rails|
|Description||AAs can execute discovery calls on specific FIPs, the IDs of which are passed by FIUs, via parameters passed during an integration between the FIU front-end and the AA client.
This is to support customer journeys that originate on the FIU front-end and involve embedded AA interactions.
|Purpose||To clarify if discovery can be done using an identifier that is different from what the user provided during registration with the AA|
|Description||A user may provide different identifier(s) (e.g. mobile number or email ID) for enabling discovery of accounts from one or more FIPs, than what was provided during registration.
|Purpose||To clarify what are considered “Strong Identifiers” for Discovery and whether additional identifying attributes can be added to these|
|Description||Strong identifiers are one of the following:
● Mobile Number
● Email ID
Additional identifiers, such as Date of Birth, PAN – can be added, as required by each FIP. Such information is stored against each FIP’s entry in the Central Registry.
All additional identifiers are to be clubbed with the Strong Identifier value using an “AND” condition.
However, are FIPs, AAs and the Registry capable of supporting the above?
|Purpose||To clarify if Aadhar Number is allowed as a Strong Identifier|
|Description||The ReBIT Technical Specification V 1.1.2 does list Aadhar Number as a Strong Identifier.
However, there are UIDAI restrictions around exchange of Aadhaar numbers, as is, between two systems – in this case, between an AA and an FIP.
Work is in progress to design mechanisms to use Aadhar, in consultation with UIDAI.
|Purpose||To clarify the scope of Account Types supported under the FI Type “Deposit” and the workflow required for expansion to joint accounts/corporate accounts|
|Description||As of now, the scope of Account Types includes:
The scope currently excludes:
The workflow details for expansion of scope to the above types is under discussion, amongst RBI/ReBIT and industry participants.
|Purpose||To clarify if information about “discovered accounts” can be shared with FIUs|
|Description||No. The information provided by FIPs in response to a discovery request is meant to be stored only at the AA.
Such information cannot be shared by the AA with an FIU.
FIUs get information for accounts that are included by the citizen, in the consent artefact, while approving the FIUs’ consent requests
|Purpose||To clarify if discovery of an account can be enabled by an FIP if the account status is NOT active|
|Description||If the status of an account is NOT active (i.e. it is either dormant or suspended or closed, e.g.), it is in the interest of the citizen for additional services (such as the sharing of account information) to NOT be authorised by the FIP. Hence, discovery of the same should also not be enabled.
This needs to be discussed with FIPs once.
|Purpose||To clarify if discovery of an account can be enabled by an FIP if the mobile number (as an identifier) does not resolve to a single customer record|
|Description||If a mobile number cannot be resolved to a single customer record, the FIP is expected to reject the “Discovery” request.
Additional identifying attributes (such as DOB, e.g.) may be defined by the FIP and collected by the AA, to sharpen the query and resolve it to a single record.