Guideline No. UA001
Purpose To clarify the user identifiers that an AA must support, for authentication during initial registration and subsequent access
Description To authenticate a user during customer registration, an AA must support taking the:
● Mobile number as an identifier

To authenticate a user during subsequent access (i.e. login), an AA must support taking either of the two below:
● Mobile number as an identifier
● VUA as an identifier

In addition, an AA may support identification and authentication using
● Email address
● Aadhar number
Stage Finalised
Guideline No. UA002
Purpose To clarify the duration for which an inactive user’s session on an AA client remains valid, once a user is authenticated
Description As per OWASP best practices, once a user is authenticated by an AA, the session remains valid for a maximum duration of 30 minutes, in case of inactivity by the user.

Is there a reason to either extend or reduce this duration?

(This guideline is to particularly enable embedded AA interactions that involve repeated invocations of the AA client from within an FIU
environment – e.g. in a loan journey, consent for loan origination is taken once and then separate consent for loan monitoring may need to be taken.)
Stage Under deliberation
Guideline No. UA003
Purpose To clarify if multi-factor authentication of a user is a MUST for authorization of sensitive actions in the AA domain
Description Currently, AAs do not employ multi-factor authentication for either registration, login, profile change or consent management actions.
Should one or more of these actions be protected via multi-factor authentication? Alternatively, are there more sophisticated means of
detecting identity fraud without necessarily resorting to MFA?
Stage Under Deliberation
Guideline No. UA004
Purpose To clarify if KYC norms as prescribed by RBI for entities regulated by them have to be followed, while onboarding users onto AA platforms
Description KYC Norms are applicable to regulated entities that deal with money flows.

While AAs are licensed as a type of NBFCs, they are unique (as compared to all other types of NBFCs) in their role of providing only consent management and data-sharing capabilities to citizens, NOT movement of money or facilitation of transactions involving money transfer.

As such, it is not required for AAs to follow KYC norms for customer registration, as applicable to other NBFCs/Regulated entities.
However, as prescribed under ReBIT technical specifications, strong authentication is a must for AAs to onboard users. This implies the usage of at least one strong identifier (mobile, email) during registration.

Such usage is both necessary and sufficient.
Stage Finalised

Back to AA Community Guidelines Summary