Bank: Multiple accounts and merchant accounts

Kyle Redelinghuys -

In this post I will detail the most recent additions to the banking project: multiple accounts per user and merchant accounts.

Multiple accounts per user

When I first started developing the project, I decided to do a one-to-one on users and accounts. The logic was that this would be the most simple implementation I could do that would allow me to still work on the more complex parts of the system. As those complex parts have been built out, it was time to go back and amend the logic to allow for a user to have more than account - a key feature for any banking system.

Previous structure

Before the change, the structure of the project was as follows:

  • UserAccount -> UserBankAccount
  • AuthAccount -> UserAccount

One user account linked to one bank account, and one auth account linked to one user account (the auth account manages user authentication and is separate to any other detail of that account). In order to implement the change, I decided to abstract away the single user account from the bank account.

Current structure

With the above in mind, I broke the link between a user account and a bank account, using a bridging table to provide a one-to-many link between user and bank account. The structure now looks as follows:

  • UserAccount -> (many) UserAccountBankAccounts
  • UserAccountBankAccounts -> UserBankAccount
  • AuthAccount -> UserAccount

The AuthAccount is still linked one-to-one to the UserAccount, allowing one set of authentication details for all of the user’s accounts.

When a user logs in now, they can retrieve all of their account details and request specifics for those accounts. One example is the retrieval of transactions against a particular account:

curl --request GET \
--url https://bvnk.co:8443/transaction/list/10/0 \
--header 'cache-control: no-cache' \
--header 'content-type: multipart/form-data; boundary=---011000010111000001101001' \
--header 'x-auth-accountnumber: 97890206-89d0-40f1-8162-af76bdf05089' \
--header 'x-auth-token: 4e8afddd-e151-40ab-835c-2ced3a1ae075' \

In keeping to REST principals, this is a GET request. The addition here is that of an X-Auth-AccountNumber header field which denotes the account to retrieve the transactions from.

The documentation has been updated. Currently, the mobile client does not allow for multiple accounts, so it will not work against this build. The mobile client will be updated to support multiple accounts soon.

Merchant Accounts

The second major addition is that of merchant accounts. For any banking system, merchant accounts are a necessity. I decided to implement along the same lines as the user accounts, that is having a bridging table which would allow for any given merchant to have multiple accounts. This links a given user (through their identification number) to a merchant (through their unique merchant ID).

Merchants also have a merchant table which lists information specific to merchants. This includes fields like address, website, decription, business sector, and contact details. All of this is intended to be public and as such these fields are all returned when doing a query against a merchant.

Merchants are also searchable much like users. We use a fuzzy matching against the search string and return a defined number of results. Currently this is 10 which I believe to be a sane limit on search. For those interested, here is how fuzzy matching is implemented in Go.

Documentation and the Postman collection will be updated this week with the new details.

Different types of accounts

When creating multiple accounts per user, it became clear that there would need to be different types of accounts that a user could open. This would also be true for merchants. As a result I decided to create a set of account types:

'savings', 'cheque', 'merchant', 'money-market', 'cd', 'ira', 'rcp', 'credit', 'mortgage', 'loan'

These are the main types of accounts used in banks currently. This also brings in our first touch on credit. As credit is a complex issue, I will be planning this out properly before implementing.

Conclusion

Now that we have multiple accounts per user and merchant accounts, we can start looking forward to extended functionality. Before that though, I want to tackle the more mundane:

  • Tests across the entire project
  • Documentation
  • Installation

The mobile app also needs to be updated to somehow handle multiple accounts, and try and get it ready for app store release. Once the app is happy, I will be deploying to our current stack and start to name the instances better - staging.bvnk.co and api.bvnk.co.

All code is open source:

If you want to chat about this project, please feel free to get in touch.