This page serves as a brief glossary of commonly used terms throughout Fusion documentation. They are covered in much more detail in Resource Types.
|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.|