A ledger API for building financial products
Like what NuBank and Square have: an idempotent, double entry ledger to handle complete loan systems.
Move money and track your accounting variables in simple API
Built to handle custom products, multiple instruments and accounting reconciliation between multiple parties.
Multi-Lender Support
Ability to have multiple lenders on-board with customization to settlement data based on their requirement.
Time Machine
See the history of any data point in real-time. Useful to answer questions like 'What was the user's dpd around this time last year?
Reconciled by Design
Track things like taxes, loan balances and liabilities in real-time, updated inline with payments
What is a ledger?
Ledger is a fully managed loan system to get your started with your next big (or small) FinTech idea. It includes an immutable double entry ledger that takes care of all your accounting variables, payments, settlements, charges etc. Along with the support for managing multiple instruments (card, UPI, tokenization) and lenders.
Loan systems can get complex. Gateway webhooks can fail. Resulting in customer’s payments getting delayed. Resulting in wrongful late fee applications. Resulting in people outside your office willing to low-key beat you up. And even if you somehow make it through, the trouble isn’t all over. Your lender, who still functions on medieval technology, expects you to support its data APIs in an absurdly peculiar format. By API we mean an Excel sheet.
Ledger handles all of that for you. It was made after several iterations and learnings of 5 years at RedCarpet and now we are sharing it with the world.
How does it work?
Events
Everything is associated with an event in the Ledger. Primarily, an event contains the metadata related to the event, time of the event and the time at which it got processed.
| Event Name | Meta Data | Post Date | Amount | Processed at |
|---|---|---|---|---|
| Card Transaction | {“swipe_id”: 321} | 2021-11-20 11:43:23 | 100 | 2021-11-20 11:43:23 |
The above event signifies a card transaction worth rupees 100. Metadata can be anything which can help you identify a particular event. In this case it’s an id of a table where the raw transaction data is stored.
Ledger entry
Each event can have multiple ledger entries linked to it. A ledger entry signifies the actual movement of money between accounts.
Let’s take a look at the corresponding ledger entry for the aforementioned event.
| Credit account | Debit account | Amount | Credit account balance | Debit account balance |
|---|---|---|---|---|
| 26346/loan/card_balance/a | 56345/bill/unbilled/a | 100 | 9900 | 100 |
To understand what the account strings mean go to the Book account section.
The account balance of both the accounts is calculated and stored within the entry. In the above example, the balance of the card balance account which got credit became ₹9900 after a transaction of ₹100. This calculation works on the actual bookkeeping principle. Here’s a table to show whether there will be an increase or decrease depending on what type of account it is.
| Debit | Credit | |
|---|---|---|
| Asset | Increase | Decrease |
| Liability | Decrease | Increase |
| Revenue | Decrease | Increase |
| Expense | Increase | Decrease |
For the accounts to remain in balance, a change in one account must be matched with a change in another account. To make sure this constraint always holds true we have designed the process in a way so it’s mandatory to have a debit and a credit account against the same amount.
Book Account
A book account consists of 4 variables. These accounts are used in the ledger entry as debit or credit. The book accounts are represented at different hierarchy levels. There can be a loan level account, a bill level account or a card level account etc. For example, a user can have a card level limit and a user level limit. User level limit will signify the total limit a user is allowed whereas the same user can have multiple cards with their own individual limits.
Let’s dissect a book account we saw above to understand how it’s represented.
| Description | Value | |
|---|---|---|
| Identifier | Is a unique identifier of a particular level. Based on the value of the identifier type column. Ex: loan_id, bill_id | 56345 |
| Identifier type | Is the level that we talked about above. The values can be loan, bill, card, user, lender etc | bill |
| Account Name | Name of the account | unbilled |
| Account Type | Type of the account. Asset, liability, revenue or expense | a |
Processes
Doing a card transaction.
A card transaction process involves a couple of events which get triggered before the actual transaction event. Let’s take a look at them.
Funds received from the Lender
Lender transfers the funds to a Nodal account. This account is usually managed by the bank’s issuer processor. We use these funds to load money into cards for the transaction to happen.
Loading the customer’s card
Before a transaction can be processed the card needs to have some balance in it. Depending on what process of money load you follow, this step can either be JIT (Just in time) load at the time of transaction happening or beforehand. Here we are showing the beforehand load.
This event loads up the balance account in Ledger and reduces the money from the Nodal account. At this point we will also call the APIs of the bank’s issuer processor to actually move the money to the card.
As can be seen, the prepaid card’s balance became 10,000 and the Nodal account’s balance got reduced by the same.
Card transaction
Now that we have money in the card, it can be used to do transactions on e-commerce websites, POS machines or ATMs.
In this entry, we have debited the user’s loan account and reduced the card balance by the same amount.
At redcarpet whenever the transaction is made by the user through his/her card a disbursement takes place in the user's CF (Card Facility) account. i.e A disbursement happens on the CF account by debiting it every time the customer uses their card to do a transaction. These transactions can happen on websites, POS machines, and ATMs.
Generating the monthly statement
Just like how in credit cards, a monthly statement gets generated showing debits and credits from the previous month, the same gets done in this step. This happens on the 1st of every month. We list all the transactions, charges, refunds, and payments from last month and show them in a statement. The statement also contains details like the minimum amount to pay, due date, and the maximum amount to pay to avoid interest (before the due date).
Accrual of financial charges
In accounting accrued interests are generally computed and recorded at the end of a specific accounting period as adjusting journal entries used in accrual-based accounting. Interest gets accrued the next day after the due date. The due date is set to the 15th of every month for all loans.
