A Q&A with Galileo CTO Jeff Currier

Moderated by John Locke, Partner, Accel

Much ink has been spilled on the transformative power of APIs across industries. For payments, the API stack is redefining infrastructure, services and platforms. Accel’s John Locke, a former Galileo board member, reached out to Galileo Chief Technology Officer Jeff Currier for a deep dive into the topic and to explore the company’s API stack. We were privileged to be able to listen in on the conversation.

John Locke: Jeff, it’s great to be talking to you about the API stack, which is a hot topic in fintech. From your perspective as Galileo Financial Technologies®’ chief technology officer, let me start by asking you to describe your company’s API stack.

Jeff Currier: At a high level, the Galileo API stack is a set of RESTful (Representational State Transfer) services that we operate in the cloud to facilitate card issuing, processing and approval, along with event notification services. What I mean by RESTful is they are simple, lightweight and fast web services that allow APIs to be easily created to develop internet applications. Our APIs are HTTP-based and built for scale with low latency, meaning we’re making it as easy as possible for clients to consume our APIs while making sure our services can grow to meet their needs—as well as their customers’—as those needs evolve. So, that’s the technical stuff, but the most important thing about our APIs is what they enable our clients to do.

Why APIs? Build more, faster

JL: Okay, what's that?

JC: Through our APIs, Galileo provides the building blocks to create the financial experiences our clients want to deliver without the overwhelming effort to build them on their own. As a platform, we don’t dictate what your products or experiences should be. We give you what you need to build them, and through those building blocks, we handle the heavy lifting by removing the complexities of developing financial products and services. Of course, you don’t need to use all the building blocks we provide, but they’re there if you need them—now or in the future. And, through the user-facing app you build, you create a unique package of opportunities for your customers. This is how the Galileo API stack supports our clients in offering products as varied as consumer digital banking to fully electronic accounts payable solutions for businesses. It also explains how clients operating in the same vertical can use Galileo’s APIs to build highly differentiated products and services that speak to the market segments they want to serve.

JL: Is it fair to say that Galileo’s APIs jump start a business?

JC: It’s absolutely fair to say that. Our APIs jump start a business in achieving its goals by relieving them of the expensive and time-consuming foundational work they’d be required to do in the absence of the APIs. It’s also fair to say that our APIs—because of their flexibility—are the foundation that supports a business as it scales.

APIs fuel banking-as-a-service

JL: So many different types of companies today call themselves “banking as a service” providers. Galileo is one of the only ones doing this at real scale. How do you define banking as a service and what does that mean to Galileo?

JC: Great question and thanks for asking. Galileo has clearly graduated to the next layer of APIs—and  banking as a service couldn’t be more on point for our business. First, banking as a service is what Galileo does—at the API level and also delivering the ancillary back-office functionality and third-party connectivity—to enable many types of businesses to offer financial services. This includes neobanks, whose primary line of business is financial services. It also includes other kinds of businesses that aren’t financial services providers, but need banking-type functionality to expand their business models, deepen customer loyalty or enhance efficiencies. We certainly have evolved to the API service layer and this, I predict, is the future of fintech.

JL: Now, let’s talk a little bit about API security. Recent research has indicated that some fintech platform APIs may have vulnerabilities. Can you tell me a little bit about your point of view on API security as a whole and what Galileo is doing to ensure its APIs are secure? 

JC: At Galileo, API security is a top priority.  Everything we do is designed to be secure by default.  That means all data and information flowing to and from our platform is encrypted, both in transit as well as at rest. We also conduct regular and frequent reviews with our information security team to ensure we meet the security standards and compliance obligations we have as an API service provider.

Hybrid cloud headaches

JL: Going back to the future of fintech and your comment about the Galileo API stack operating in the cloud, I assume you mentioned it because it’s a differentiator for Galileo. Isn’t it the general perception that all fintechs operate in the cloud?

JC: That’s the perception, but it’s not entirely accurate. Fintech and financial services in general have been slower to move fully to the cloud, largely because of structural reasons, just one of which is the fact that a lot of the players have invested in their own data centers and associated technology. What’s most common in fintech is having some part of the operation in the cloud. This could be their web experiences or even portions of their API stack. In contrast, Galileo is moving fully to the cloud. We’re currently migrating current clients to the cloud, and new clients are being implemented directly to the cloud.

JL: So, you’re saying many fintechs operate in a hybrid cloud environment with some functionality in the cloud, some not. Why has Galileo chosen to be fully cloud based?

JC: Because maximizing the benefits of operating in the cloud requires you to be fully in the cloud. While a hybrid operating environment may be acceptable in some situations, it’s not well suited for many Galileo clients whose transaction volume is growing exponentially with sometimes frequent and unpredictable activity spikes. A hybrid environment forces you to support multiple operating environments, which creates friction and inefficiencies for both the client and their customers. A lot of people underestimate what it takes to run a data center operation effectively at scale—even if you work with a major cloud provider.

JL: What kinds of challenges are you referencing?

JC: Well, capacity management is a challenge, along with the logistics of having the right type of hardware in the right locations, as well as having staff in those spots to support localized issues. And, finally, when you get the staffing and the capacity you need, you still find yourself still needing to ‘rack and stack’ as your traffic volume grows. In other words, adding more hardware to your data center—putting the blades or systems into the racks that provide power and pipe networking. But that’s only the start of what you need to scale up to meet growing demand in a traditional data center environment. Assuming you can source and install the equipment quickly and have sufficient additional floor space in your data center—big assumptions, by the way—there are additional factors complicating capacity expansion. For example, you need multiple backup power generators and multiple points of ingress and egress on the network side. You need multiple carriers in place and more than one data center, typically three. Then you need the capacity to deal with power outages, like those caused by backhoes, which have a historically testy relationship with data centers. The complications are crazy, and they’re really hard to solve. The bottom line is racking and stacking doesn’t happen on demand. Regardless of how fast you can acquire and install incremental equipment to handle volume increases, you can’t predict surges. If your 18-month advance planning is off by even a few percentage points, you could find yourself scrambling to meet your clients’ needs. More typically, however, you’re building in buffer capacity to deal with potentially increased loads, which means you’re also paying the extra capital costs that come along with that insurance. Committing fully to the cloud—which, in our case, is Amazon Web Services—is a significant effort we’ve been working on for more than a year. We believe the commitment is well-justified by the benefits to our clients, their customers and, of course, Galileo.

Future-proof: All in on APIs and the cloud

JL: And those benefits are…?

JC: Galileo and our clients derive three key benefits by fully moving into the AWS cloud: resiliency, elasticity and future proofing. AWS enhances our resiliency by spreading the transaction and API traffic between Galileo and our clients across several availability zones located 10 to 100 miles apart within a region. This protects us against localized disasters, like our friend the backhoe taking out a single data center, and also widespread disasters, like a hurricane affecting the entire East Coast. Closely related to resiliency is the benefit of being co-located with our customers, which is especially important as Galileo expands globally. First, we can expand faster because we won’t be building local data centers. And, second, we’ll serve our clients from data centers in relatively close proximity to where their customers are transacting—not halfway around the world. This physical proximity minimizes latency, so our clients’ apps will respond seamlessly for better customer experiences. Then there’s elasticity—the ability to lean in when we have sudden surges in demand requests. With AWS, we’re able to tap into new computing capacity virtually instantaneously. There’s no waiting for humans to react or to rack and stack, as we were talking about before. It enables us to scale on demand, and it gives our clients assurance that we’ll be able to handle their needs, regardless of how fast or how unexpectedly they—or our other clients—grow. Finally, there’s future proofing. As a tech person, I have a love/hate relationship with this word because sometimes I think it’s a fake marketing word, but it’s relevant here. Working with AWS, we have access to a slew of new services and integration points that we wouldn’t have access to unless we bought or licensed the software and hosted and ran it ourselves. Should I continue?

JL: Thanks, I’ve got it. So, why aren’t all fintechs in the cloud and—to your point—operating fully in the cloud?

JC: Well, over time they will be. It takes a huge organizational commitment to make the move, and not everyone is willing or able to take that on while supporting its clients’ ongoing requirements. Others will catch up in time.

JL: Thanks, Jeff, it’s been a pleasure.

JC: Agree completely. Thanks for the opportunity to share my thoughts.

Jeff Currier As chief technology officer and top tech executive, Jeff Currier is responsible for Galileo’s product engineering and new product development. Prior to joining Galileo, Jeff led the technical development of the successful SoFi Money product, built on the Galileo Platform. Earlier in his career, he led engineering teams at Amazon Web Services, Twitter and Microsoft. While at Microsoft, Jeff was a founding member of the Azure SQL database team and led the initial launch of the service along with the rest of the Azure platform. Jeff’s alma mater is the University of Michigan.

John Locke John Locke joined Accel in 2010 and helps lead the firm’s growth fund. Over the last decade, he has led or worked closely on Accel's investments in Braintree/Venmo (acquired by PayPal), Crowdstrike (CRWD), Galileo (acquired by SoFi), GoFundMe, Lightspeed (LSPD), Monzo, QMC Telecom, The Zebra, Tenable (TENB), WorldRemit, and Xero (XRO) and a number of other companies. John graduated from Princeton.