Glossary

An Account corresponds to one single liability or asset ledger and represents one integral value in a specified currency (balance).

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.

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

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.

A specification for minor variants of Products within a family to enable marketing and sales activities like Promotions, Discounts, Customizations, and so on.

A Provider is a virtual construct created to ease the handling and governance of the lifecycle of the kind of products it produces.

Payment channels are the rails on which the money moves and include various payment networks and settlement schemes like Visa, Mastercard, IMPS, NEFT.

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.

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

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.

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.