The fund collection service was built out to solve a problem in Rubix, the Integrated Business Travel and Expense Management product developed at Zeta.

The problem can be described as follows:

We needed to issue some funds into the fusion** funding account of the company. For doing this, the company has to deposit the respective amount into some accessible physical/reachable bank account of Zeta. After receiving the funds, Zeta on behalf of the company will issue funds into the fusion** funding account of the company.

If we want to generalize this problem we can describe it like this: A person wants to transfer the funds from any type of source bank account to any type of destination bank account.

To generalize the problem consider the following use cases which will help us build the core modeling of the problem.

1. The person doesn’t have the required currency to credit the destination account, let’s say the source account is a USD account and the destination account is an INR account. It may also be possible that the destination account is a closed-loop rewards point account.
2. The destination account is not accessible to the customer, for example, if the destination account is a virtual account or an NRE(Non-residential External) account, in these cases a direct transfer of funds is not possible.
3. The person wants to do several small transactions and the transaction itself accrues some cost, in certain cases doing a bulk transaction could be less expensive. Thus a service provider could facilitate these transactions incurring fewer expenses.

All the above use cases can be fulfilled by an external service provider.

We can have 3 types of accounts that can facilitate these transfers.

• Destination/FundingAccount — The account to which the customer eventually intends to transfer the funds.
• Collection Account — The physical and reachable bank accounts owned by the service provider which it uses to collect the funds from the customer.
• Reserve Account — The account owned by the service provider will be used as the source for the movement of funds into the destination account. It’s important to note here that the reserve account and the destination account have to be transactional.

Just follow the below diagram for the actual interaction of all the entities.

Apart from the core model, there are some application-specific business processes. The fund collection service will require an extension to service these processes. A brief overview of these processes:

1. Mechanisms provided to deposit funds into Collection Account.
2. Mechanisms provided to notify the Service Provider about deposits into Collection Account and request a credit to the Funding Account.
3. The Reserve Account to be used for each request from the customer.
4. Business constructs for fulfilling the requests:
5. Value conversion rules: Deposit X value and Receive Credit for Y value. (The currency of X and Y could be different)
6. Fee and charges for the service; Could be expressed in terms of destination account currency, source account currency, or both. (There could be multiple parameters for accessing this; We could keep this out of scope)
7. Mechanisms provided to publish the relevant Collection Accounts to a customer. Only a subset of Collection accounts owned by the service provider may be relevant for the purpose of the Customer.

Currently, the service has been extended to handle the fusion** transfers.

** Fusion: Fusion is a platform by Zeta to help all stakeholders. It is a BaaS (banking-as-a-service) platform, for fintech developers, for managing accounts, issuing physical, digital, or tokenized cards and controlling spends on channels, levying fees/charges/interest, etc. In its simplistic form, Fusion provides you with a set of APIs that can help you build and solve for your fintech use case that you are going after thereby reducing your prototyping cost, iterations to minimum-viable-product, and time-to-market for your go-to-market product.

Thank You

Speaker- Priya Panthi

Edited by- Phani Marupaka