Guideline No. AD001
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?
Stage Under deliberation
 
Guideline No. AD002
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.
Stage Finalised
 
Guideline No. AD003
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. 

  • The different identifier(s) provided must include atleast one strong identifier (i.e. mobile no or email ID)
  • The AA must authenticate the new identifier as well, before sending the discovery request to the FIP
Stage Finalised
 
Guideline No. AD004
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?
Stage Under Deliberation
 
Guideline No. AD005
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.
Stage Under Deliberation
 
Guideline No. AB006
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: 

  • Savings and current accounts that are singly held by individuals (this includes current accounts held by sole proprietorships)

The scope currently excludes:

  • Accounts held jointly – regardless of the “mode of operation”
  • NRE/NRO accounts
  • Accounts held by companies other than those registered as a sole-proprietorship

The workflow details for expansion of scope to the above types is under discussion, amongst RBI/ReBIT and industry participants.
Stage Under Deliberation
 
Guideline No. AD007
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
Stage Finalised
 
Guideline No. AD008
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.
Stage Under deliberation
 
Guideline No. AD009
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.
Stage Finalised
 

Back to AA Community Guidelines Summary