| 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 |
