Ahmed, thank you very much for coming in to speak to us today. Let's kick off with the easy one: can you tell us a bit about your role as CTO at Caxton?

Absolutely. As the CTO, I lead a team of around fifteen people, covering everything from data, mobile, front-end, back-end, DevOps, to QA.

My role is dynamic. Honestly, no two days are the same.

Despite being over 20 years old, Caxton still operates with the agility of a startup, which presents unique challenges. The company maintains its startup DNA but has the stability of an established organisation. It has undergone numerous iterations in terms of platforms and products, and we have a loyal customer base.

I originally joined as one of the engineers, and I’ve grown with the platform from a senior engineering position [to CTO]. I've had to drive and shape it in various ways. The current platform, and the APIs built on top of it, reflect the vision I had in mind.

The job involves aligning the development team with the tech stack, the business strategy, and the vision. As a hands-on CTO, especially in a build environment, there's a constant influx of queries and challenges that need immediate solutions. Working with the executive and product teams, and the QA and development staff, we drive our agenda forward. This approach is pre-calculated; we are an agile business, not just in following principles but in our ability to pivot quickly when opportunities arise. This agility has been crucial, especially during events like the COVID pandemic, where our team's ability to innovate and adapt was key.

As the CTO of Caxton, I see my role as connecting the different parts of our platform, much like roads linking towns to cities, and building the country, that is our platform.

It sounds like the path that you had from a senior engineer to CTO gives a different perspective. Could you share more about your professional journey? Specifically, I'm curious about the early stages of your career. What was the initial inspiration or motivation that led you to embark on a career in this field?

I began my academic journey in telecoms and electrical engineering. However, after a year, I found that it didn't quite ignite my passion. This realisation prompted a period of self-reflection, where I pondered over my past year's studies and my true interests. I had always had a knack for technology - being the go-to person for tech issues like antivirus solutions or bypassing firewalls for gaming. This led me to switch to software engineering, where I excelled. I was able to take part in an Erasmus study programme in Sweden. The Swedish educational system, which emphasises self-learning, was a stark contrast to what I was used to and proved to be an invaluable character-building experience.

After graduation, I moved into risk management, joining a small company in 2008 that worked with major banks and insurance companies. This coincided with the onset of the 2007/2008 financial crisis. Within four months, I was unexpectedly promoted to a technical lead role and sent to India to manage the development team. This experience was a rigorous test of my abilities, but it also allowed me to excel in an environment that valued quick decision-making and innovation. My time at this company, lasting until 2014, was a significant period of growth and learning for me.

How long did you stay in India during that time?

Six weeks. A transformational six-week period in Kerala, India, surrounded by lush landscapes.

I continued to balance my career with academic pursuits: managing company deployments while finishing my dissertation. This period was intense, marked by long work hours followed by university commitments.

But I enjoyed it! That's the key theme in all this. I love what I do, that hands on element, just being exceptionally involved in the technical day-to-day and reaching the peaks that you're setting out to reach.

In 2015, I joined Caxton, a company then mainly known for its prepaid cards. The early days were challenging, filled with thorny questions about our existing systems. I scrutinised the codebase, questioning architectural decisions and the multiplicity of databases. This inquisitive approach was vital, especially since, before 2015, Caxton operated on a different platform. The transition involved building a new system and migrating all data, resulting in a complex, data structure. My first six weeks were spent reverse-engineering this data to understand our customer base and data architecture.

This task was pivotal, leading to a successful transition but not without challenges. Overcoming these led to my appointment as the technical lead. I focused on establishing development structures and coding standards, introducing concepts like PRs, QA, and DevOp. This effort laid the foundation for a robust, API-led infrastructure, marking a significant shift in Caxton's technological approach and setting the stage for future advancements.

This leads perfectly to our next question about the API-led infrastructure at Caxton. Could you elaborate on the development and implementation of this approach? What benefits have you seen since adopting this approach?

For about five years at Caxton, I likened my work to gardening: separating, organising, and fortifying our digital infrastructure. This process involved transitioning from a monolithic to a micro services architecture, clarifying and segmenting data, and enhancing overall system resilience, availability, and scalability. Our platform served a wide range of users, from consumers to business clients, with the sales and account management teams being significant internal users. This period was marked by continuous feedback from users, driving product development and improvements.

During this time, we faced challenges in understanding our data and developing robust API gateways, load balancers, and other advanced features. Around 2020, we began to see the fruits of our labour, with significant improvements in customer engagement and API usage. This shift was catalysed by the pandemic, leading to a dramatic increase in API calls and a new era of API-first strategies.

The shift towards API-first strategies is also borne out by public statistics. In just 18-24 months, the landscape changed significantly. For instance, Google's data shows a stark increase in Open Banking API calls over time. In June 2019, the number was approximately 1.9 million per month. By April 2023, this number skyrocketed to 1.1 billion monthly API calls, highlighting the rapid adoption and integration of API technology in recent years.

Let’s tie that back to the business case. What was the CEO’s business rationale behind this?

This transformation was envisioned and encouraged by our CEO – he frequently asked us about security, scalability, and our API capabilities. Initially, our focus was primarily internal; but he encouraged us to expose our API externally, which has fundamentally changed how we operated and interacted with the external world.

This shift was particularly evident in the development of our mobile app. Initially, the app was burdened with excessive business logic, lacking a proper API communication with the backend. About two years ago, we decided to overhaul this approach. Despite experimenting with various technologies like Xamarin, we ultimately chose React Native for its cross-platform capabilities. This decision marked a leap of faith towards a unified codebase for both Android and iOS. Recognising the shift to a mobile-first society, we refocused our efforts from a primarily website-centric approach to enhancing our mobile app. This change was driven by the realisation that most of our consumers preferred a mobile-first, app-centric experience.

Consequently, we doubled down on our API strategy, integrating and collaborating with clients who wished to connect to us. These initial years of integration were exciting, as we were hands-on in assisting clients to connect with our backend. This approach not only fostered close client relationships but also contributed to their growth and ours.

It’s intriguing to understand how you distinguish your services in the market, particularly in defining your position as a software and financial service provider. Could you elaborate on what sets your offerings apart from competitors in this space?

Firstly, we should clarify that we’re not a bank. This distinction is crucial in understanding our services. We offer an end-to-end, customer service-driven solution. When you think about financial services, it encompasses a wide range of components – FX, payments, cards, accounts, customer service, and back-office operations. Essentially, we're offering an entire financial services ecosystem

When you plug into our API you are accessing our Software as a Financial Service. Although 'banking as a service' is a common industry term, it can be too vague. It includes regulated entities requiring licenses and purely SaaS-type players. In our case, the Caxton SaaFS is a comprehensive financial services ecosystem, which includes both financial tools and back-office services. full-stack pre-defined solutions which understand the business’s context – product logic, processes and of course the ability to make compliant payments – everything that’s required to embed financial services into your application so your businesses can design products and launch them rapidly – something that couldn’t be more crucial in the fast-paced marketplace of today.

Of course, integrating with the core banking infrastructure is critical; and many players use Open Banking.

At Caxton, being early adopters is part of our ethos, and everyone who joins us appreciates this dynamic. We enjoy taking risks, albeit in a controlled manner, to stay at the forefront of innovation. So we’ve been on a bit of a pioneering journey with Open Banking over the last six or so years. We've faced quite a few challenges as some of the connected banks have updated their systems over the years. Our recent partnership has been a significant achievement in this regard. Integrating open banking was a venture into uncharted territory, with limited guidance and documentation. We navigated through numerous edge cases, learning that banks often lag years behind industry trends in terms of innovation.

That's an intriguing point about the complexity of open banking, especially regarding edge cases. Could you share some specific examples of these edge cases that you've encountered?

There are so many – we could talk about them for days! For instance, some providers operate on a mainframe system, which struggle to compute or confirm transaction statuses. It's essentially unable to provide clear responses. On the other hand, providers using Java can provide a more reliable response, indicating whether a transaction has settled or will settle, and if the person involved has sufficient funds. You may see this across different institutions within the same group. This discrepancy exemplifies the challenges in integrating diverse banking systems, where one might confirm a request within hours while another remains uncertain.

How do you see Open Banking evolving? Where is it headed?

It's great working with banks, but they tend to lag. For example, a significant advancement is Variable Recurring Payments (VRP), a major new feature for Open Banking [payments]. However, not all banks fully support these, especially for larger-scale, business-driven transactions such as payroll payments. When faced with numerous edge cases, possibly influenced by KYC requirements, we experience limitations.

Our goal with our API is to create an adaptable, SaaS-like ecosystem. We envision open banking as an ideation platform, constantly evolving as technologists push the boundaries.

Do you think perhaps we might see different APIs? Are we going to see more flexible API's that can support more use cases are essential?

The trend is now shifting towards instant cross-border payments and settlement. Various players are involved, including central banks and FinTech firms, which establish nodes in different countries for this purpose. If you have sufficient resources, you can purchase these nodes and facilitate instant cross-border settlements. However, compliance and KYC play crucial roles, especially in transactions across borders. For example, in London, everything is strictly regulated with KYC and AML standards. This raises the question: how do these regulations apply to international transactions, such as sending or receiving money from countries with different compliance standards? The next step in cross-border payments involves addressing these compliance issues at an international level.

How do you and your team, particularly the engineers, stay current with all these rapid advancements?

We really love what we're doing here. Everyone on the team, they're deeply into FinTech - from our engineers to our tech gurus and architects. It's not just a 9-to-5 for us; there's real camaraderie. We're always on our toes, keeping up with the latest in innovation, security, and compliance. Our CEO is extremely keen on that. Plus, we're all about top-notch customer service. Staying ahead of the game? That's our thing, I guess.

It sounds like innovation is critical – but you operate in a highly regulated industry. In your experience, do you view regulation as a catalyst that drives innovation or a barrier?

In my view, regulation is essential in the field of technology. It acts as a grounding force. Without regulations, there's a risk that technological advancements could escalate too quickly, potentially leading to unforeseen consequences. Think of regulation as an anvil that keeps the balloons – in this case, our innovative ideas – from drifting aimlessly into the atmosphere. It's a necessary balance, really.

Reflecting on your journey and the challenges of navigating regulatory landscapes, what are the key milestones or achievements that you are most proud of?

Honestly, I'd say my entire job is a highlight, as it's been a journey from start to finish – and we're not done yet! There are so many stories to tell. One of the key achievements is the architectural overhaul of our card processing engine. It's the powerhouse behind our multi-currency wallets, enabling seamless conversions for customers. For example, if you're spending in euros but have only USD, the transaction still goes through smoothly, with conversions happening behind the scenes.

This platform was built on an event-driven architecture consisting of roughly 40 micro services, with each service playing a critical role within the card payment lifecycle.There were two core aspects to this particular sub-system. The first family of services interfaced with MasterCard, managing things like balances, fees, and fraud detection. The second part is where customers get to load money onto their cards, with all these operations feeding into a central system that aligns with our FX trading platform. Those few months of intense work were really something!

I can imagine the complexity, especially at the intersection of new developments and established systems. That must have been a significant challenge to navigate.

All our products and programs are built on this system. It's adaptable, with various levers and limits that you can set as needed. However, these are subject to regulatory guidelines.

The complexity of our system becomes apparent when dealing with transactions in different currencies. For a straightforward Euro transaction, for example, you have the standard transaction fees. However, imagine a Euro transaction involving multiple balances in different currencies. Our system can seamlessly handle such transactions, each balance supported by quotes based on specific margins. This demonstrates the intricate data rights and the robustness of our software in managing complex financial operations.

If you look back at your career, what advice would you give people starting out and possible looking to become a CTO?

CTOs are a diverse bunch, there's no one-size-fits-all blueprint. So you don’t need to worry about matching an archetype – in my case, I didn't find someone quite like me! One of the most important things as a CTO is that you must love your work: you'll be constantly challenged and held accountable for the technology. You need to have confidence in your decisions. You’ll need to be inquisitive, and able to investigate the details while maintain ingsights of the big picture. Technical fluency is important, as is learning from mentors with different perspectives – from the technically brilliant to the data-driven thinkers.

CTOs are important organisational leaders, so another crucial skill is communication – not just with developers, also with senior stakeholders and customer service teams. Finally, you need to be able to bring your team with you: knowing when to motivate, and how to spark enthusiasm.

How would you say your responsibilities change going from technical lead to CTO?

In part it has been about taking on more responsibilities, gathering more experiences. But I've also learned to gradually disconnect and get some sleep. I used to be deeply involved in everything – from full-stack development to day-to-day operations. I've had to let go of some of that. Implementing a product-driven approach with managers leading squads has really allowed me to take a step back. It's tough transitioning from being deeply involved to overseeing things, but it's a necessary shift. Do I still code? Absolutely, during those late-night sessions. It's like constantly tending to your own garden, always evolving and growing.

CTOs often take ownership of product management. How do you manage the boundary between product management and technology? When do you think it's appropriate to treat these as separate roles, and how do you navigate the challenges that this differentiation presents?

I go back to the analogy of the platform and technology as the soil, and the product as the trees and garden. Five years ago, they were one and the same. But introducing product managers, who focus solely on the product aspect – like enhancing our B2B side and sales strategies – has been immensely beneficial. It's allowed me to concentrate on ensuring the platform's reliability, scalability, and relevance. Meanwhile, our product team is busy finding new revenue opportunities from customers.

Thank you so much for your time and valuable insights today. It has been a pleasure having you with us. We greatly appreciate your contribution to the conversation, and we wish you continued success in all your endeavours.