• Credit

    US flag
  • Credit

    US flag

About Account Holder

This article covers the important functional concepts related to Account Holders and Application.

Account Holder

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:

  1. Collect Account Holder details like name, date of birth, OVD, Vectors and so on.
  2. Create and submit the application with the collected details.
  3. Issuer reviews and approves the Application.

Key Terminologies

Term Description
SKU * Dictates the allowed set of activities and transactions that can happen between the applicant and the issuer.
Spool * Defines the following:
  • Relevant details needed as a part of application
  • Workflow for processing the application
  • Details of relationship formed once the application is approved

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

Application States

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

  • Enrichment

    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.

  • Review

    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.

  • Assessment

    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.

  • Provisioning

    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.

  • Accepted

    Application has been accepted by the Issuer. Terminal state, application can not be revived.

  • Rejected

    Application has been rejected by the Issuer. Terminal state, application can not be revived.

  • Requires Intervention

    In case any discrepancies are found or the system runs into error.

States of a Stage

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.