Requirements

Functional Requirements:

• users should be able to view all the transaction history.
• users should be able to generate financial statements capturing all the transfers/receipts
• users should be able to add/remove a specific bank account/card account to the financial system.
• users should receive notifications of the states of the transaction
• users should be able to make transactions across countries/continents/currencies.

Assumptions: Assume both the sender and receiver are onboarded in to the system using user id and account number. Below the line requirement is to send money to someone not in the system using just the phone number.

Non-Functional Requirements:

• prioritize consistency over availability. Any financial transaction has to update/deduct at the same time in a single atomic transaction. If it is otherwise - though the system would be available, but could lead to duplicate transactions through retries etc.
• the payment system has to be secure - any account/card/PII data should be secure both at rest and in transit.
• System should be able to handle atleast 1 million transactions per hour and 5-10M reads/hour
• System should be able to identify fraud transactions - either runtime or within an short time span (< 24 hours) and address any potential financial loss

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

• GET /viewTransactions/{userId}?limit=20&cursor='' -> transactions
• GET /viewStatements/{userId}?startDate=''&endDate -> statements
• POST/addAccount/{userId} -> status boolean
  • Body: {content: encrypted(accountNumber), accountType: encrypted(accountType),
  • routingNumber: encrypted(routingNumber)
  • bankName: encrypted(bankName)}
• DELETE /deleteAccount/{userId}-> status boolean
  • Body: {content: encrypted(accountNumber)}
• POST/makeTransactionIntent/ -> transactionIntentToken
  • Body: {senderUserId: encrypted(userId), receiverUserId: encrypted(userId),amount: int, currency: string}
• POST /makeTransaction/ -> status boolean
  • Body: {transactionIntentToken: token, senderAccountNumber: encrypted(accountNumber), receiverAccountNumber: encrypted(accountNumber)}

High-Level Design

All our apis reside behind an api gateway. The api gateway also takes care of authentication and rate limiting. We intend to delineate the write and read paths in to separate flows. This is because although the system might not be read heavy as a regular bank account, it is reasonable to assume every 1 write could have potentially 4-5x reads and we do not want to overload everything on a single database server. This also ensures that the writes are consistent always and the reads are highly available

1. To make a transaction, the client first calls the makeTransactionIntent service. This service captures every change in state of a given transaction. So this service creates a transactionIntentToken which is transmitted in all the following stages of transaction for both authentication/verification. This transactionIntentToken can also be used as an idempotency key to avoid any retries. Every transaction intent has to have a unique transactionIntentKey.
2. Next the client makes the makeTransaction api call with the transactionIntentToken and the card/account details. The makeTransaction makes an atomic transaction in to the write database - deducting from the sender account and updating the receiver account in one single flow. If either of the step fails, the entire transaction fails.
3. the updates from the makeTransactionIntent, makeTransaction all happen to the write database.
4. To add/delete a bank account to the system, the add account or delete account service update the write database
5. The viewTransactions api will enable to read all the transactions - this will have a pagification capability to capture all the transactions through a transaction history.
6. From the write database through a CDC the read database gets updated and from the Read database the reconciliation with bank account for balance availability to avoid overdraft, credit limits etc to authorize transactions.
7. From the bank account through a notification system we notify both the client and also update the write database with the status of the transaction.
8. The view statement api will fetch bank statements from an s3 storage. The statements are generated using a periodic statement worker - this could run overnight to capture that months statement till that point in time and overwrite the same in s3. Every end of month statement would be captured with a clear naming convention.

Database Design

• users - userId, userEmail, userPhone, userLocation, userCountry
• accounts - accountId, userId, BankName, accountType, accountNumber
• transaction - senderUserId, receiverUserId, amount, currency, fraudStatus
• transactionIntent - transactionIntentId, senderUserId, receiverUserId, currentStatus,

Initially let us get started with the assumption that all the databases are standard SQL tables - postgres would do good for the time being.

Detailed Component Design

1. using a combination of a public key/private key mechanism the PII/card information can be encrypted in transit/rest and cross verified at the makeTransaction service. This also opens vulnerabilities as to what happens when the private key is in the hand of an attacker? So a hashing mechanism along with a nonce generated by the client which would be cross verified server side would add security.
2. The read database would be scaled by creating partitions based on user id. Alternatively if any querying is likely to happen over locations, we could use something like geospatial indexing to avoid the database looking over all the rows.
3. There is a chance that the reconciliation from the bank account could arrive slightly delayed - meaning that it could be a delayed arrival in to both our kafka stream (use watermarks) to factor in late arrivals of events in the event stream for any fraud analaytics.
4. There still exists a potential vulnerability for a duplicate transaction of the exact same amount on the exact same card by the exact same user if the bank reconciliation worker does not notify that the balance is available and the first transaction went through successfully.