O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

The Great British API Client Bake Off #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018

1.871 visualizações

Publicada em

By Dave Tonge (Moneyhub Enterprise)

Publicada em: Internet
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

The Great British API Client Bake Off #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018

  1. 1. The Great British API Client Bake Off
  2. 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. 3. Moneyhub, aggregation & the road to open banking
  4. 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. 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. 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. 7. Onboarding to the Open Banking Directory
  8. 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. 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. 10. How we built our integration
  11. 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. 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. 13. Lessons Learnt
  14. 14. Verifiable conformance is invaluable ● Reduces support costs ● Speeds up integration ● Reduces implementation costs
  15. 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. 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.