Engineering Challenges in Developing a FinTech Platform
Published: 2024-07-07 11:21:43

I have spent over 13 years working in FinTech engineering and product development across multiple organizations.
From my experience, let me share a few common challenges in developing and engineering FinTech platforms, such as Digital Wallets, Accounting, Transactions, and Payments.
Here we won't discuss common system challenges like performance, scalability, availability, reliability, and risk & security. 

**1. Accounting**

Maintaining double-entry bookkeeping is crucial. When we add money to an account, another contra account must be deducted. In accounting terms, when we credit one account, we need to debit another account simultaneously. This allows us to trace platform money movement and manage internal reconciliation effectively.
Categorize all accounts into two major classes: Assets and Liabilities. Remember:
When an Asset is Debited, it increases.
When a Liability is Credited, it increases.

**2. Atomicity & Transaction**
Any operation or group of operations should be atomic in nature. ACID-compliant databases are more suitable for this requirement. For example, if you want to perform a payment, multiple operations are involved:
1. Deducting the amount from the payer's account & Crediting the amount to the payee's account
2. Deduct payment fee from payer and increase income account
3. corresponding VAT transaction
4. Logging the three transaction details.
4. Some other state update
All five operations must be atomic, meaning either all five operations succeed or all fail. There should be no scenario where operations 1, 2, and 4 succeed and operations 3 & 5 fail. We can achieve atomicity by using RDMS transactions feature.

**3. Consistency**
All write operations should be consistent. For instance, when we update a balance, it should be immediately reflected across all master nodes. Any subsequent read operation should retrieve the updated balance.

**4. Double Spending issue**
In digital money systems, double spending means a sender can attempt to send or pay the same funds to multiple recipients simultaneously. 

For example:
User A has a $100 balance.
At the same time, User A tries to:
Send $100 to User B
Send $100 to User C

To prevent this issue, we need to implement a proper locking mechanism. This will ensure that once a transaction starts, the balance is locked, preventing any simultaneous transactions and avoiding double-spending.

**5. Concurrency in Balance update**
After each transaction or accounting event, we need to update the account balance. If two concurrent requests try to update the balance, there is a possibility of an incorrect or "dirty" balance. 

For example:
User A has a $100 balance.
User A receives $100 from two accounts simultaneously.
The first request reads the balance as $100 and updates it to $100 + $100 = $200.
At the same time, the second request also reads the balance as $100 and updates it to $200.

This results in an incorrect balance update. We need to handle this concurrency issue to ensure accurate balance updates.

**6. DeadLock handling**
Using a database lock can lead to deadlock, so we need to handle it properly.

**7. Duplicate Request handling and Idempotency**
The same transaction request or operation can reach the server multiple times due to:

- Double-clicking from the browser
- Re-transmitted network packets
- Client retry mechanisms

A FinTech platform should be able to handle this issue by implementing a unique request ID and idempotent key for each request.

**8. Internal Reconciliation **
All money movements on a FinTech platform should be reconcilable almost in real-time. This ensures that any unauthorized alterations by intruders or internal resources are detected. If someone alters data or balances at the data layer, the discrepancy will be immediately reflected in the internal reconciliation report.

**9. External Reconciliation**
When a FinTech platform communicates with other systems, it must be reconciled with the third-party state. Every event should be traceable using both internal and external reference IDs.

**10. Audition & Tracing**
All state change events must be auditable. If any event occurs, such as a transaction, balance update, account state update, or any other data change, the following information must be captured:

- Creator
- Modifier
- Inputter/Authorizer (Maker/Checker)
- Creation time
- Modified time
- Complete change history

This ensures thorough tracking and accountability for all actions.

**11. Append only nature and data immutability **
All events and change history should be append-only in nature. Events such as transactions and balance changes should be immutable. This ensures that once an event is recorded, it cannot be altered or deleted.

**12. Celebrity account/wallet problem **
This issue can arise when an account receives money from millions of senders (e.g., a biller receiving payments nationwide on the last payment date). Regular merchant account lock won't work here. The FinTech core needs to handle these balance and transaction events differently. Similarly, a merchant wallet might need to send/payout/disburse money to millions of receivers at once.

**13. Decimal Problem and rounding **
Decimal and rounding issues can occur in amount and balance calculations. These need to be handled properly. In Java, it is recommended to use BigDecimal instead of Double for precise arithmetic operations.

**14. Insight reports**
It's essential to implement insight reports for maintaining the integrity of a FinTech core accounting platform. Examples include balance sheets, trial balances, cash flow statements, payable and receivable reports, and profit and loss statements. These reports provide critical insights into financial health and performance.

**15. More important features **
Several common feature-level challenges need to be handled properly in FinTech platforms, such as:

- Day-end process and close of business procedures
- Adjustment and compensation transactions, reversals, and refunds
- Sundry and escrow management
- Account state management (PENDING, ACTIVE, FREEZE, HOLD, BLOCKED, CLOSED, DEBIT_BLOCKED, CREDIT_BLOCKED)
- Management of holding balances and pending transactions
- Implementation of the Inputter/Authorizer (Maker/Checker) concept to ensure that large transaction events involve at least two persons for execution

We believe every tech company, whether a startup or enterprise, needs a digital wallet/account/ledger platform to:
Receive, store, and move money
Manage internal accounting and finance
Support both open and closed-loop wallet/account economies
Model complex transactions, such as payments, fund collections, repayments, and loan disbursements.

**At LooFi, we have addressed all these challenges. **The LooFi Digital Wallet/Account/Transaction Engine can be used in:

- FinTech
- MFI/MFS
- E-Wallet/Digital Wallet/Payment Platform/Virtual Card
- BNPL/Lending Platform
- WealthTech/Investment/Crowdfunding Platform
- Digital/Neo Banking
- ERP
- Any tech enterprise or startup that wants to receive, store, and move money

If you need a digital wallet/account platform, contact us. Our solution can be used independently or integrated with your existing platform. We offer cost-effective assistance in various models:

- B2B API SaaS model
- On-Prem Deployment
- Co-Development & Consultation

Email: azomshahriar05@gmail.com, lognifintech@gmail.com
WhatsApp: +8801674242986

These are not the only challenges when building a robust FinTech platform. There are many more. If you are facing any specific challenges, please comment and share your experience.