Back in 2019, when I first delved into the realm of bank integrations, my initial searches yielded little beyond official documentation. Fast forward four years, and a similar quest over a drink at a local bar still didn’t yield fruitful results. It was during this moment that the idea struck me to embark on a series of articles detailing our experiences integrating with banks at Circit — sharing our user scenarios, acquired insights, and knowledge.
The initial focus of these articles will revolve around our utilization of bank integrations, elucidating the challenges we’ve encountered, the evolution of our products, and our firsthand encounters. Subsequent publications will delve deeper into practical aspects such as certificate management, signature validation, authorisation procedures, onboarding protocols, and the intricacies of regulatory compliance.
Within our company, we boast several products leveraging bank transaction data, one of which is Verified Transactions. In essence, we offer expedited access to clients’ bank data during audits. With over 2,300 active integrations spanning traditional banks, fintech startups, crypto wallets, and more, Circit operates under the regulatory oversight of the FCA in the UK and the CBI in Ireland. As an Account Information Service (AIS) provider, our operations solely entail read-only access without any financial transactions.
Undoubtedly, one of the most arduous aspects of our solution development lies in the integration process.
Although the world of technology is on the track to unification, we are still far from it, and here is why:
There are several frameworks available: CDR, PSD2, SX2A, STET and many others, each bank, and sometimes even individual branches, independently choose which framework to use and whether to use it at all.
Local regulators often have their own requirements for local banking offices, which can have many implications, from restrictions on the data provided to authorisation and authentication methods.
Different banks are at different stages of implementing the innovation, often have old systems behind a fancy interface, or all kinds of Frankenstein systems, don’t be surprised when the same endpoint can return json or xml depending on the scenario.
While the tech world aims for unification, several factors hinder this progress:
- Multiple Frameworks: Numerous frameworks exist, such as CDR, PSD2, SX2A, STET, each chosen independently by banks or even individual branches. This leads to fragmentation and inconsistency in approaches to data handling and security measures.
- Regulatory Diversity: Local regulators impose varying requirements on banking offices, from data restrictions to authorisation and authentication methods. This adds complexity and divergent practices across regions.
- Diverse Bank Infrastructure: Banks operate with diverse infrastructure, ranging from antiquated systems masked by modern interfaces to complex hybrid setups. Consequently, endpoints may return data in different formats (e.g., JSON or XML), complicating integration efforts.
These challenges highlight the need for standardised practices and interoperability within the banking sector to facilitate smoother operations and enhance security measures.
The absence of global standards in the banking sector leads to banks making independent decisions, often diverging from industry trends. This lack of uniformity has posed significant challenges for us, particularly in the early stages when our knowledge and experience were limited. Here are some of the assumptions we made and the lessons we learned:
- UK Interpretation of PSD2: We assumed integrations with banks would align with the UK interpretation of PSD2. However, this led to incorrect integration of many domain states, terminology misalignment, and a domain model based on flawed implementation of the directive.
- Uniform Framework Implementation: We believed all banks using a particular framework would implement it in the same manner. In reality, the flexibility of frameworks resulted in diverse implementation options, leading to significant refactoring efforts after initial integrations.
- Consistent Data Provision: We expected all banks to provide the same data as per contracts. However, discrepancies arose due to regulatory constraints, commercial motives, or incentives to use paid APIs, complicating our integration efforts.
- Uniform Domain Terminology: We assumed domain terminology would be interpreted uniformly across banks. However, inconsistencies emerged, such as varying interpretations of balance sheet types.
- Authorisation Complexity: Authorisation proved to be a challenging aspect of integration, requiring additional client settings that often lacked intuitiveness. Initially focusing on OAuth2 authorisation, we later discovered over 20 different authorisation methods.
- Transaction Scale: We underestimated the scale of transactions, leading to suboptimal data storage choices. What we initially expected to be several thousand transactions per account with 14-character amounts turned out to be millions of transactions with significantly larger amounts.
- Bespoke Bank Solutions: Contrary to our expectations, over 50% of integrations involved financial institutions’ own solutions rather than standardised frameworks.
Each of these assumptions resulted in challenges that we successfully navigated. An evolutionary approach to solution development and adaptable architecture were instrumental in overcoming these hurdles.
In conclusion, navigating the intricate landscape of bank integrations has been a journey fraught with challenges, lessons, and evolution. As we reflect on our experiences, it’s evident that the road to unification in the banking sector is long and winding, yet not without its rewards. By embracing an evolutionary approach to solution development, we’ve transformed setbacks into opportunities for growth and innovation.
As we look ahead, we remain committed to sharing our insights, experiences, and technical learnings with the wider community. Through collaboration, adaptability, and a shared commitment to excellence, we can overcome the hurdles that lie ahead and continue to pave the way towards a more unified and efficient banking ecosystem.
Thank you for joining us on this journey, and we look forward to embarking on the next chapter together.
