Glossary
This page serves as a brief glossary of commonly used terms throughout Fusion documentation. They are covered in much more detail in Resource Types.
| Term | Description |
|---|---|
| Account | An Account corresponds to one single liability or asset ledger and represents one integral value in a specified currency (balance). |
| Account Holder | Account holder is a real/legal customer to Fusion. Drawing from the real world analogy, account holder could be an actual person who holds an account at a bank or could be a legal entity like a corporate, merchant, so on. Account holders can also be headless (anonymous), in which case we may not be able to ascertain the identity of the customer using identifiable documents. |
| Artifact | Artifacts are entities of the customer’s interest that a bank can produce and maintain. For the purpose of this document we call fundamental entities such as Account, Payment, Resource, Transaction and Wallet as Artifacts. |
| Bundle | Bundle is a concept that enables financial institutes to create and combine several products that could be sold together. Examples include an ICICI Salary account which gives you a Savings account bundled with a VISA Coral Debit card. It is also a manifestation of the application form and workflow. A Product can only be availed by an end-customer through the construct of a Bundle. |
| IFI | Issuing Financial Institutes (IFIs) are institutions like banks that have the license and the authority to store accounts, create wallets, process payments, and many more. |
| Form Factor | A Form Factor is a manifestation of a payment instrument. |
| Individuals | Technically referred to as Real Account Holders who can be onboarded as directed by the IFI. |
| KYC | Know Your Customer (KYC) is a process by which financial institute obtains, ascertains and validates information about the identity of a customer. |
| Product | Packaging of an Artifact for a specific customer. It can also be thought of as a set of business rules that define the associated Artifact. These may include, among other things, transaction policies, interest/charges, risk/compliance controls, associated accounting practices. |
| Program | A specification for minor variants of Products within a family to enable marketing and sales activities like Promotions, Discounts, Customizations, and so on. |
| Provider | A Provider is a virtual construct created to ease the handling and governance of the lifecycle of the kind of products it produces. |
| Payment Channel | Payment channels are the rails on which the money moves and include various payment networks and settlement schemes like Visa, Mastercard, IMPS, NEFT. |
| Payment Instrument | Each authenticatable vector associated with the Resource is called a Payment Instrument. Some of these Payment Instruments may have real-world physical form factors, whereas others may have digital-only representations. It can be used for authentication in any financial or non-financial transactions. Fusion will support multiple forms of payment instruments including payment cards, mobile numbers, email addresses, usernames and passwords, digital tokens, and so on. |
| Payment Products | Payment products are business constructs created to allow IFIs to manage different kinds of payment Artifacts, along with the lifecyle and associate policies. |
| Policies | PPolicies are associated configurations added as part of a product definition to allow permissible behaviors in every financial and non-financial transactions.Policies could also be used to define and alter the basic business rules of the products, the risk management for the product and to monitor the utilization of products. |
| Resource | A Resource is an entity representing a digitally authenticatable vector of an Account Holder. It can be used for authentication in any financial or non-financial transactions.The purpose of a resource is to enable grouping of various payment instruments that may logically belong to a customer and administer various policies on that collection and on the payments that may originate using the payment instruments associated with it. A Resource, as previously mentioned, is associated with one or more payment instruments. In a majority of use-cases, resources are bundled with an Account Holder. However, it is completely possible for a resource to exist independently. Examples include Metro Rail Cards, where payment transactions may be required with no notion of an identifiable account holder. In such cases, payment instrument is a bearer instrument. |
| Sandbox | Sandbox framework is a generic access control framework used to control access to a Fintech. |
| Transaction | Transaction is an instruction to the financial institute to transfer funds from one account to another account at the institute or an external institute using any of the inter-bank settlement systems carried out between payer and payee. The payee may have an account on Zeta system or any other bank. Kindly note that a transaction may not necessarily have a notion of a payer and a payee. It could purely be a transfer of funds between accounts or withdrawal of funds by the account holder at the bank teller counter.Successful payments translate to one or more transactions. A payment performed through a Resource associated with an Account Holder is deemed as a Transaction instruction issued by the Account Holder. |
| Fintech | Fintech is an entity that utilises the banking license of the governing IFI to provide products and solutions that can benefit their specific use case. |