Bank project: Integrating in the real world
banking infrastructure

Bank project: Integrating in the real world

Kyle Redelinghuys
Kyle Redelinghuys

After building out a rough version of an iOS app to showcase the functionality, I’ve put a lot of thought into the next steps to take.

The immediate follow on:

  • Fix the iOS app, make stable
  • Integrate required functionality into the server for the above
  • Write tests
  • Documentation

This can be written over the course of a few weeks and is also ongoing. In the greater scheme, the project should have some real world use. With the iOS app it gives a platform for the feature deployment.

Deployment options

The next question is what do we want to do with the app? The broadest goal is to create a bank, which involves the managing of money and a whole bunch of regulation. Aside from being prohibitively costly, this cannot be done as a side project. The bank could also be backed by another, giving us the functionality we require at a fraction of the cost and time. While not the full goal, it’s a great step to the final product.

Secondary implementations involve a far wider variety. This can be anything from inter-person transfers, merchant accounts, POS payments, and more. This can be done in a few ways, three of which will be discussed in this post in some detail. These could be implemented in a side project, but as soon as you start moving people’s money it becomes a bit more serious. In the early stages I would use it almost exclusively and ramp it up down the line.

VISA Direct

One implementation is to integrate with VISA using their API, found in detail here. This would allow all the functionality one would require to make payments and transfers, effectively becoming one layer of a bank.

There is no sandbox for this, and you need to be sponsored by a financial institution. Safe to say, this option is out for the immediate future.

Stripe

A further abstraction on the payments ecosystem would be to use a provider such as Stripe. Stripe (and other payment providers) offer merchant accounts which will allow:

  • Alice to pay Bob
  • A third account to take a transaction fee

This will allow transfers between people, and the holding bank account to make a profit. This fee will be in addition to the fee of the payment provider in use, which will make these transfers quite expensive. At a high level this allows one aspect of a bank’s functionality to be implemented.

This could be implemented in a side project/POC will less overhead than the above options.

NFC and Card Readers

A third option is to go into the merchant space. This is one of the more interesting options out of the initially attainable as it involves both hardware and software. Apple does not allow access to the NFC interface by default, so a separate piece of hardware would have to be used. A lot of NFC readers (made for payments) come with chip and magstripe readers, allowing a full implementation of a payment solution.

This would in turn require a merchant account, but the software would be super interesting to get into. I’m not sure how deep this rabbit hole goes, but could be good to find out.

The ideal

In an ideal world, the goal would be to have a custom issued visa/mastercard debit card, linked to a bank account that you have some influence over, linked to a mobile app which directly interacts with the account in real time. The only way I can see this happening is through bank sponsorship.

This is the most likely option to follow, so I’ll be looking into what is needed for bank sponsorship, and if there any institutions that would be the sponsor with minimal overhead.

Conclusion

While not that much code has been written, I’ve been using the app and it has been great. With the app getting into the real world, I am dying to link it to some real money, and making some real payments using it. With this in mind, Stripe seems like a good option, but might be off course away from the end goal.

The next moves will centre around the ideal listed above, while tidying up the app, server, testing and documentation.