This document discusses the author's experience building an integration with the UK's Open Banking Directory as the CTO of Moneyhub. It provides background on the author and Moneyhub, an overview of their road to using Open Banking APIs after previously screen scraping, details on onboarding to the Directory, how they built their integration using OpenID Connect and separating by financial institution, and lessons learned around the importance of verifiable conformance and not assuming banks have automated testing.

1. The
Great British
API Client
Bake Off

2. ➢ Moneyhub, aggregation & the road to open banking
➢ Onboarding to the Open Banking Directory
➢ How we built our integration
➢ Lessons learnt
○ What went well
○ What went badly

3. Moneyhub, aggregation & the
road to open banking

4. About Me
● CTO at Moneyhub
● I’m an active contributor & now co-editor
of the FAPI specs
● FAPI WG Liaison Officer to UK
OpenBanking Implementation Entity
● UK Expert at ISO TC68 SC9/WG2 -
Financial APIs
● Technical Representative for the Financial
Data & Technology Association
● Key proponent of the use of CIBA spec for
financial use-cases
● Represent AISPs at OpenBanking & the
FCA.

5. About Moneyhub
● UK Based Fintech established since 2011
● We build an intelligent financial assistant
and work with our partners to improve the
financial wellbeing of their clients
● Founding member of FDATA
● Active with the Open Banking Working
Group
● Active in lobbying the CMA to require a
“common” OpenBanking API
● One of the first Account Information
Service Providers in Europe

6. The Road To OpenBanking
I’ve been a reluctant screen
scraper since 2013.
Nat Sakimura came to the UK in
June 2016shortly after starting
FAPI.
The timing was perfect &
thankfully we were able to get the
evolving FAPI security profile
adopted by UK Open Banking

7. Onboarding to the Open
Banking Directory

8. Open Banking Directory
Identity Verification was the
hardest part.
Once onboard, it is excellent to
work with.
Certificate Authority & issuer of
software statement assertions.
Contains the well-known openid
configuration urls for all the
banks.

9. Well Known Uris
These are incredibly useful from
an implementation perspective.
Our implementation retrieves
these dynamically and can thus
cope with changing uris, or
response types, etc.
We hope that further discovery
metadata will be made available
in a similar way.

10. How we built our integration

11. OpenID Connect
● Used certified open-source
implementation of OpenID
Connect
● Unfortunately had to fork the
code (temporarily) to deal with
non-conformance by the banks.
● Some of the banks are now fully
conformant
● We are in favour of certification
for OpenBanking relying
providers as well as the banks.

12. Architecture
● One code base for OAuth 2
based integrations
● Separate instance per financial
institution
● Provider specific config and
specific “adapters” to work
around provider quirks
● Better than “shared library” or
“monolith” approach
● The auth part of any integration
is the hardest and most error
prone - FAPI conformance tests
help a lot.

13. Lessons Learnt

14. Verifiable conformance is
invaluable
● Reduces support costs
● Speeds up integration
● Reduces implementation costs

15. Don’t assume big banks have
automated test suites
● We acted as an (unpaid) QA function for many banks
● We are now pushing for regular runs of the
conformance suite

16. Standards & open source
● Connecting to standards based OpenBanking APIs has
been far easier than working with a commercial
provider that has proprietary APIs.
● Open Source standards compliant relying party
implementations increase security of the ecosystem
and lower costs for fintechs.