Building the Moveable Type of Embedded Finance: Spotlight on Jatin Salla, Head of Credit at Highnote

In 1450, Johannes Gutenberg perfected an innovation that would forever change the way humans shared data: the moveable type printing press. While mass printing existed before, it was still an arduous process rife with potential for error. Woodblock printing required entire pages of books to be carved by hand onto a wooden block, and any errors in carving meant that the whole block had to be scrapped and carved again. Jatin Salla, Head of Credit at Highnote, explains how this was somewhat the state of credit card issuing in embedded finance before Highnote came along. In this Q&A, Jatin shares why this is so significant for the future of credit card issuing, what’s exciting him in the credit-issuing space, and his overarching philosophy on building the credit team at Highnote.

Q: Jatin, we talk a lot about our domain-driven architecture and our GraphQL-based API. Explain why this is so important for credit card issuing.

A: It's been really interesting to trace this journey. If you think back to history class, you may remember the invention of the printing press. The press itself wasn’t really the innovation; it was the movable type that allowed data to be shared much more easily and rapidly. Long before that, books were painstakingly copied by hand, often by monks or scribes who devoted their lives to the task. You could think of this in the same way as card issuing 1.0. Then, there was an improvement with woodblock printing. This meant scribes only had to spend time carving one book that could be copied into significantly more books with the same amount of effort – rather than just one-to-one replicas. This is similar to card issuing 2.0 – pioneered by some of the first modern card issuers. Now, companies like Highnote are emerging: card issuing 3.0.

There are two critical aspects to what makes us so powerful: Domain-driven architecture and GraphQL. Domain-driven architecture is like the moveable type, and GraphQL is like the alphabet. It was the 26-letter alphabet that made it possible to easily switch out individual letters in a movable type press, and the same is true for domain-driven architecture and GraphQL.

Both are crucial for credit card issuing because it allows for a modular and flexible approach to product development. In traditional systems, making changes or adding new features often required extensive reconfiguration, which could disrupt the entire system. With domain-driven architecture, each domain, such as fraud detection, user management, or transaction processing, operates independently. This means we can innovate and implement changes rapidly within one domain without affecting others. For credit card issuing, this translates to faster rollouts of new features, better customization for our clients, and a more resilient and adaptable system overall.

Q. Our credit customers are among some of the most innovative, pushing the boundaries of what’s considered standard in a card issuance program. Can you share some things you’ve seen that are personally exciting to you?

Our system is designed for high scalability using a completely event-driven architecture. Leveraging technologies like Temporal, we have created workflows that are both highly efficient and flexible.

What’s been most exciting is that through these workflows, we have quickly built an exceptional built-from-scratch reward system and a robust credit subledger responsible for many loan servicing capabilities, such as interest calculation and repayment waterfall. What this means is that our customers are party to a best-in-class credit program experience. We didn’t launch credit as an afterthought or acquire another credit provider and tried to enmesh systems. We crafted this infrastructure intentionally and thoughtfully, not only to be responsive to the needs of our customers but also to work seamlessly within the context of our overarching system.

To support ongoing innovation, we also created our credit capability to accommodate both our underwriting processes and allow customers to manage their own underwriting through a collaborative approach. We always have the belief that our customers can anticipate the needs of their market better than we can, so we give them the freedom to build for that if they so choose. Additionally, our system features a time machine simulation that enables customers to perform comprehensive testing, including account aging, interest and fee calculations, and retroactive statement generation.

We are also working on a variety of innovative use cases for our embedded finance customers and exploring the use of AI to further enhance our underwriting processes. I should mention – all of this innovation is being driven by an engineering team I’ve had the pleasure of working with and is among the best in my experience.

Q. What’s your overarching philosophy regarding building and managing the credit product here at Highnote?

It's easy to get distracted by shiny object syndrome, so our philosophy is to focus on fundamentals first. A lot of the very basic elements of card issuance are incredibly important to get right, but they can become easily missed in the mad dash to build out the most exciting feature or most differentiated product. We hold a different view: build a solid foundation so you can innovate on top of it. Our team operates on the speed and scale of much larger teams simply because we built the foundations that allow us to do so.

For example, one area where this really stands out is in our release schedule. I’ve worked at much larger companies where doing even quarterly releases was considered an impressive feat. At Highnote, we do releases daily. That would be impossible unless we had spent the necessary time to ensure the whole of our underlying foundation worked together with each new element we introduce.