This article covers the important functional concepts related to Account Holders and Application.
An Account Holder is any person or corporate that has a banking relationship with an Issuing Financial Institution (IFI). The various types of Account Holders in Fusion world as follows :
- Real Account Holder (RAH): Also known as Individual, a Real Account Holder uses the banking products created by fintechs on Fusion. RAHs are identified and authenticated using various identifiers (phone number, email) and authentication procedures (KYC) prescribed by regulatory bodies. Examples of RAHs include prepaid account holders.
- Legal Account Holder (LAH):
Also known as Corporate, a Legal Account Holder is any commercial business defined as a legal entity by regulatory bodies. Examples of LAHs include fintechs, partnership firms, merchants, and so on. Fintechs using Fusion to build their products are identified as LAHs on Fusion. Corporates who avail those products are identified as LAHs as well.
There is a single account holder per IFI. For example, if fintech A and B have an account holder with the same IFI, an applicant associated with both these fintechs will have a single account holder associated with the IFI. KYC Limits apply to the aggregate of all accounts held by the account holder. If the KYC state of an account holder is upgraded to Full KYC state by fintech A, then the same KYC can be utilised to issue full KYC bundle by fintech B.
An application is a request from the applicant for establishing a banking relationship with the issuer for its offerings. An application contains details the issuer needs before forming the banking relationship.
The process of creating an Application is similar to opening an account in the real-world banking system. In the real world, you would ideally go up to the bank to fill up the application form to, say, apply for a prepaid card. With application APIs, the same API can serve as a real-world application form for any banking service, such as Prepaid Card.
Creating an Application for RAHs consists of the following steps:
- Collect Account Holder details like name, date of birth, OVD, Vectors and so on.
- Create and submit the application with the collected details.
- Issuer reviews and approves the Application.
|SKU *||Dictates the allowed set of activities and transactions that can happen between the applicant and the issuer.|
|Spool *||Defines the following:
|Spool Validator *||Defines rules for validating an application. Currently, only JSON schema validators are supported.|
'*' : Defined by the issuer
Note: Typically, the Financial Institution (IFI) configures an application workflow as per their requirement. A fintech shall abide by the application process set by the Financial Institution (IFI).
After the creation of an Application, it moves through various states. Each state provides crucial information about the Application. The stages of the application enable Issuers to define complex workflows for application processing, giving them more control over the process of issuance. The issuer can define the process they require an applicant to go through. For example: After the applicant provides their demographic details, the Issuer can define a stage for data enrichment where the PEP (Politically exposed person) status of the applicant is fetched from a third party service. Post this, in the assessment state, the Issuer’s employee can, then, take a call on accepting or rejecting the application.
Sourcing [a.k.a data capture]
Applicant provides data requested by the Issuer
Additional information about the applicant, as requested by the Issuer, are enriched in this stage. This information may be collected through external services as well and may require manual input as well.
Example: Based on the information provided by the applicant, Issuer can check if the applicant is a politically exposed person (PEP) and add that data point to the application.
Application is reviewed for completeness and correctness of information. This can be performed manually or by a system process.
A bot/person acting on behalf of the Issuer will verify the completeness of the application in this stage.
Issuer analyses the applicant’s eligibility for the relationship requested. Issuer can, then, accept,reject, conditionally approve or request for more information.
Example: Based on the PEP status and the OFAC (Office of Foreign Assets Control) status of the applicant, Issuer can approve or reject the application.
Once an application is approved, this is the stage where all the artifacts requested by the applicant (prepaid account, VISA card, etc.) are provisioned. At this juncture we say that a relationship has been successfully established between the Issuer and the applicant.
Example: the Issuer, depending on the data points of the applicant, can issue them product A, B or C.
Application has been accepted by the Issuer. Terminal state, application can not be revived.
Application has been rejected by the Issuer. Terminal state, application can not be revived.
In case any discrepancies are found or the system runs into error.
Each application is supposed to be in 3 states
- INITIATED - when the given stage of the application has been initialized
- COMPLETED - when the given stage of the application has been completed
- FAILED - when the given stage of the application has failed for some or the other reason
The fintech can only play around with the DATA_CAPTURE stage by marking its state as COMPLETED once all the required sections have been adequately completed and filled.
Vectors are unique identifiers used to identify an Account Holder. Examples of Vectors are phone numbers and email IDs.
To get Account Holder details using Vectors, see Get Account Holder Details using Vectors.