This post is part of a series on a project I am doing to build banking architecture.
As I found myself faced with an 8 hour layover in Frankfurt, Germany I decided to put the time to good use. I mentioned in my last post the two pieces of functionality left outstanding before a fully fledged client could be implemented, this functionality was:
- Listing of accounts
- Deposits
Listing accounts
The listing of accounts is open for now: any user can retreive the full list of users on the system This will help the bank market flourish, and the functionality will be scope limited after testing. The bank currently has no ties to any real world money, but anyone who downloads the app can pay anyone else who has the app. To keep the payments simple, we are listing all the accounts on the system. This will be displayed as a list on the client device when making a payment.
The implementation is simple: using the same token auth I added an additional code for the acmt type. Using a code of 1000 a user may now retrieve an entire list
of accounts on the server.
TOKEN~acmt~1000
This will return a json list of accounts.
1~[{"AccountNumber":"52d27bde-9418-4a5d-8528-3fb32e1a5d69","BankNumber":"a0299975-b8e2-4358-8f1a-911ee12dbaac","AccountHolderName":"Redelinghuys,Kyle","AccountBalance":0,"Overdraft":0,"AvailableBalance":0,"Timestamp":0},...]
Although fields account balance, overdraft and available balance are all present, they are 0. This is due to this return being a collapsed struct. We could perhaps create another type of struct that
removes these fields for the specific purpose of returning account lists. For now, this is sufficient.
Now that we have a full json list of accounts, we can iterate through on the client application and show the list. The account number will be used when making a payment, and we can display the account holder name to the user for readability.
Deposits
I thought it would be great to enable more payments through the system, so that users could spend more than the 100 initially allocated to their accounts. A simple implementation of a deposit is now implemented, where a client need just make a call with the deposit type and amount and like magic it gets added to their account. Obviously, this will not be the final implementation as there are zero safety checks. Deposits will be integrated into banks and ATMs so we will work the implementation to suit the use case.
For now, the use case is “let me deposit X into my account”. This amount is deposited into the client’s account, minus fees, and the fees are added to the bank’s holding account.
TOKEN~pain~1000~AccountNumber@BankNumber~DepositAmount
The account and bank numbers are included for sake of clarity (explicit over implicit), but can be removed as the account number is linked to the token. However, when multiple accounts per user are implemented, this will be necessary.
Conclusion
Once the above two pieces of functionality are implemented into the client, we will have a fully fledged payments solution in place enabled by mobile. These payments are tied to digits only and hold no value, but will showcase the ecosystem and expose what can be done. I’m really looking forward to it.
The code is available on Github.