After APIs, webhooks...

December 6, 2020

We hear a lot about APIs as financial institutions open up their services for public access, but webhooks can be just as useful for user experience in personal finance management.

APIs are more passive whereas webhooks are more pro-active.

This makes a difference from a programmatic point of view, which then affects user experience.

You can imagine this difference with e-mail for example.

Imagine a time before push notifications. Without push notification, the manifest practice is to "Check mail". Remember those quaint days when we used to push that Send/Receive button? That's API call for you.

While we can code applications in such a way as to check an API very often, it's not very bandwidth-compute-energy efficient.

Webhooks are much better. Like push notification, applications gets notified when a transaction happens and changes its state accordingly.

Along with the change of state, any other triggers or reactive components can then come alive, a much better pattern :)

More on what webhooks can do for Prudent UX here...

Stripe's excellent webhooks

Wikipedia entry on Push technology in general (with examples of how it is implemented, including long polling, which I think is not ideal)

In-game stats: The ideal Prudent UX

December 6, 2020

Vito Chin

The very end goal for Prudent's UX is to achieve the kind of instantaneous dashboard we get in games.

Instantaneous dashboard in games

In a (computer) game, you get a precise, numerical state of your current player role (be it the player's character itself, or the city/country/kingdom that the player manages). The range of statistics are very comprehensive (i.e. your own XP, health levels, population in your city, the gold you have, iron, grain, exchange rates, etc.) and is of course the most accurate reflection of the state of your game being.

How does this translate?

Prudent should be like this. Whenever you check your Prudent dashboard and analytics, you should be able to see the most accurate reflection of your current financial state. Any expenses you'd just made, interests you had just received minutes ago, salaries that had been banked-in, etc. should be reflected :)

This scenario is more of an ideal currently as you will have to import CSVs/statements from institutions into your ledger whenever you want to get an updated view.

There's a few update extensions which doesn't require you to manually get transaction CSVs/statements available but these are mostly for prices more than transactions, which brings us to the next topic...

Great APIs and webhooks can make this happen!

I am optimistic that Prudent can achieve this speed parity with games in the near future as banks and financial institutions open up their services with APIs and webhooks. I wish the read-only ones for transactions can be opened up earlier than the mutative ones. A gradual opening of banks and financial institutions to API calls from and webhooks to citizen developer applications or even intemediaries will allow individuals to enjoy the ideal UX...

A developer's hopes for Open banking in Singapore

December 5, 2020

Vito Chin

This article on The Business Times is interesting:

Open banking APIs a bigger threat to Singapore banks than digital entrants: DBS Research

While it focuses on the disruptive forces of open banking on traditional banks, I am more excited because it seems hopeful that Prudent users will finally be able to make Bank Account Enquiries (one of the three use cases on MAS' API page)

Per the article: "open banking may enable consumers to aggregate their banking, insurance and investment information across banks and financial institutions on a single platform"

This is exactly what Prudent need! Currently, Prudent extensions gets these information by means of texts and PDF imports, which is not exactly the best user experience, but it works...

If this upcoming 😉digital service for financial planning😜 will draw inspiration from PSD2, there should be an OBIE like API that allows secure access to the Account Information interface. To this end, there are three interesting aspects:

1) Registration with a National Competent Authority

Open banking initiatives typically requires 3rd party developers accessing customer data to be registered with a National Competent Authority. I hope this is done on a tiered basis, i.e. the criteria for read-only access to retail banking transaction data should not be prohibitive for citizen developers and individuals making available creative apps! I think it's reasonable considering the read-only nature and with user-consumer consent. Payment initiation and funds confirmation approval criteria can be higher.

2) Sandboxes

Sandboxes can be a double-edged sword. On one hand, it provides a comfortable environment for institutions, developers and user-consumers to figure out how and what things can be done. The flip side is when everyone gets too comfortable playing in the sandbox and do not move on.

Well, if the latter is the case, might as well have individual sandboxes where developers can access actual data of their accounts. In this case, perpetual sandboxes are totally fine! After all, programming is not an exclusive skill and tools can be made available for users to utilize these sandboxes without any coding (i.e. by re-using readily available code and clients).

3) Just JSON will do...

Lastly, if read-only APIs still seem a little daunting, the very least that can be done quickly is to provide transaction exports via e-mail in JSON instead of CSVs and PDFs. Sigh! I also wish trusted browser makers can make headless HTTP clients exclusively for API use, that will really spur the API economy! After all, from a security perspective, how different is it to browse these data vs programmatically using these data?

Selifishly, these are ideas on what helps Prudent and its users. Nevertheless, I hope it provides some glimpse into what a developer hopes for in open banking, however representative that may be. 🙏🏻