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, as per ReBIT Circular No. ReBIT/AA/2024-25/01 dated January 10, 2024.

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.

Stage Finalised
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 customer, 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 customer for additional services (such as the sharing of account information) to NOT be authorised by the FIP.
Stage Finalised
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