Issuing Financial Institute (IFI) is an institution that has the authority to offer financial services like accounts, loans, wallets, payment processing, and many more. For example, State Bank of India, HDFC Bank, ICICI Bank, RBL Bank, IDFC First Bank.
Fusion has partnered with leading IFIs like RBL and IDFC First Bank, and its open platform is backed by these IFIs. Zeta is the Technology Service Provider (TSP), while the actual accounts and money are being stored and maintained by the IFI.
In Fusion, fintech is a technology firm or company that leverages Fusion’s capabilities to construct banking products and services. IFIs provide the required legal and regulatory support, while Fusion provides the tools to build these banking solutions. Fusion’s modular architecture allows fintechs to build solutions for their employees, partners, suppliers, and so on. These solutions are also marketed commercially to other prospective customers—retail and corporate.
Consider the following use-cases for a better understanding:
Shared Spends: Fintech provides a solution to its retail customers, consisting of a common Account for all members of a family. A member funds the Account and all members receive cards to spend funds from the Account. The primary member can also define certain policy constraints on the spending, like set maximum limit for ATM withdrawals, block usage after a certain time, and so on. This is particularly useful for families with young adults and senior citizens.
Salary Disbursement: Fintech constructs a salary disbursement solution for a food-delivery company. Instead of a bank-issued salary account and debit card, company-branded cards are provided to the food-delivery company’s employees. Every month, salaries are disbursed to those cards, and employees use them like traditional debit cards—for ATM cash withdrawals, to pay for online purchases, swipe at merchant’s POS machines, and more. This helps the company eliminate the time, effort, and cost required while opening salary accounts with a bank.
An Account is an atomic unit of asset or liability maintained by IFI for their Account Holders. It corresponds to one ledger in the accounting system, and thus represents an integral value of balance in a specified currency. Simply put, Account is the entity that holds the Account Holder’s funds or money.
Although maintained for individual Account Holder, Account can be accessed by multiple Account Holders based on the privileges provided.
An Account Holder is a representation of a customer of services of the IFI. An Account Holder may hold zero or multiple Accounts with the IFI. Creating an Account Holder consists of submitting an application request for the applicant with details. Account Holder application is issuer-specific, requiring KYC verification.
Bundles are key offerings that enable you to package feature-rich business solutions or products (Account and Payment Products). Bundles can also be personalized (combining Account and Payment products) according to the Account Holders’ requirements.
In general, a Bundle consists of the following:
- Account Products
- Set up and modify pre-configured products.
- Configure balance policies, for example, to set up minimum balance.
- Configure transactional policies, for example, to set up/restrict withdrawal limits.
- Payment Products
- Set up and modify pre-configured products.
- Associate payment instruments like cards, NFC with the accounts.
- Associate incoming and outgoing channels like Visa, MasterCard, and RuPay.
- Enable fund transfer services (in and out) like IMPS, NEFT, and RTGS.
- Create and apply transaction policies for spend control.
Fusion provides the following pre-created Bundles that are used to offer liability products such as prepaid accounts to Account Holders. You may have some custom needs that are not part of pre-configured features. Contact Zeta Support for any custom needs.
General Purpose Reloadable (GPR) Bundles allow Account Holders to reload their accounts. Based on KYC profiles, fintechs can allow users to utilize disbursed funds at POS, ECom terminals, and so on - GPR Min KYC, GPR Full KYC, GPR Shortfall KYC, GPR with ATM Support and GPR without ATM Support.
Gift Bundles are non-reloadable accounts that you can offer to your customers. These are bearer instruments i.e. an Account Holder who owns a gift card is entitled to utilize the gift amount.
Funding Account Bundle is used to create Funding Accounts for fintechs. Fintech can then disburse funds from their Funding Account to Customer’s Account. Funding Accounts are maintained on the Zeta system to keep track of the transactions that a fintech and its associated entities perform. Zeta may fund fintech’s Account basis standing instructions from the Issuer or request from fintech.
Transaction refers to the movement of funds from one Account to another. Funds can be transferred within an IFI or between IFIs using inter-IFI settlement systems. To understand from the perspective of accounting, think of it as a set of debits and credits that affects the asset and liability side of contributing ledgers. These ledger entries are made according to the principles of double-entry bookkeeping.
An Account Holder can initiate a Transaction directly with the IFI without using any Payment Instrument. For example, transferring funds to another Account Holder using IMPS. Also, a Transaction does not always involve a payer and payee and can purely be a transfer of funds between Accounts. ATM withdrawals, online purchases, and paying a shopkeeper are all examples of Transactions.
Transaction captures dozens of attributes. One major attribute is transaction_code which specifies the type of Transaction. The system provides grammar to identify the Transaction types based on the attributes of the Transaction. Several other attributes could be as follows:
- Value of the Transaction
- Merchant Category Code (MCC) of the Transaction. MCC is a unique four-digit code listed in ISO 18245 used to classify businesses based on the products, trade or services they provide. For example, 5251 for hardware stores, 5462 for bakeries, 5661 for shoe stores.
- Time of the Transaction
- Location of the merchant
- Location of the Account Holder
- Card number of the Account Holder
A Payment is a specific type of Transaction carried out between a payer and payee. As with every kind of Transaction on Fusion, Payment involves fund transfer between Accounts, and the Accounts involved here belong to payer and payee. Examples include Account Holders swiping their prepaid card at Merchant’s POS machine and online purchases at E-Commerce sites.
Resource is the logical grouping of various Payment Instruments that belong to an Account Holder. For example, cards (a type of Payment Instruments) are grouped under a Resource. When an Account Holder is issued a Product using Bundles, a Resource with a unique identifier is also generated for them. The Resource contains information regarding the various Payment Instruments (for example, card) assigned to the Account Holder. An Account Holder may have several Resources of the same or different types.
You can specify various rules or policies to control the Account Holder’s spending. These policies can be implemented on a Resource, affecting all Payment Instruments in that Resource, or individual Payment Instrument in a Resource. For example, limit the number of ATM withdrawals on the card, block usage of card at POS machines, and so on.
Every Payment involves a device or Payment Instrument through which the Account Holder authenticates their identity. In this release, the supported Payment Instrument is cards. When an Account Holder swipes their prepaid card and enters the PIN at a merchant’s POS machine, they are authenticating themselves and confirming that they are the rightful cardholder.
A Payment Instrument has the following fundamental attributes:
- The ability to authenticate the bearer.
- Facilitate funds movement.
Transaction Policies are rules that you configure to allow or disallow transactions based on specific attributes. Fusion offers an extremely flexible and expansive policy framework for VBOs that can adapt to any regulatory body requirement as well as internal corporate policy. Based on your business needs, you can create intricate policies using a combination of attributes like transaction limits, aggregation constraints (daily, monthly, quarterly & yearly limits), validity, time period, balance and many more. Also, Transaction Policies can be applied at various entity levels like Product, Account Holder, and Account.
Some of the common use-cases include:
- Blocking/unblocking ATM, e-commerce, and POS transactions.
- Disallowing spends on a debit card after a certain time period.
- Setting daily, weekly, monthly, or yearly transaction count limits.
- Setting minimum/maximum balance amount.
A webhook is a notification system that allows you to receive alerts and notifications about important business process flows. You can register to events and choose to receive real-time event messages to your secured application endpoint. Such messages may save you time and effort to track the key activities that are crucial to your business.
Interceptors are HTTPS endpoints with the extra functionality of returning a response. The host of the interceptor then consumes the response and incorporates it in the request flow. Each interceptor point provides a request payload contract to the interceptor and the acceptable responses. The contract specifies the behavior of the flow based on the response sent by the interceptor.
Contact Zeta Support for more information on the back office applications.