Card Processor 101 with Braulio Lam from EQ Bank

Podcast Episode

Audio Player

00:00 | 37:40

More Info

Fintech Layer Cake
Card Processor 101 with Braulio Lam from EQ Bank
Apr 24, 2025 | Season 3 | Episode 5
Lithic

In this episode of FinTech Layer Cake, Reggie and Ali are joined by Braulio Lam, Senior Director of Engineering at EQ Bank, to unpack the essential ingredients of selecting and integrating a card processor.

With experience across multiple processors and fintech startups, Braulio breaks down what to look for in API documentation, how to assess a processor’s operational and customer support readiness, and what a real-world integration looks like.

From technical deep dives to agile banking transformation, Braulio offers practical, tactical insights for engineers, product leaders, and anyone navigating the complexities of payments infrastructure.

Transcript

Reggie Young:
Welcome back to Fintech Layer Cake, where we uncover secret recipes and practical insights from fintech leaders and experts. I'm your host, Reggie Young, chief of staff at Lithic. I'm joined by my Lithic colleague, Alli Nilsen, who's head of banking partnerships.

On today's episode, we chat with Braulio Lam from EQ Bank. Braulio is a seasoned entrepreneur and founder and has led engineering and product functions at successful fintech startups in Canada, like Berkeley Payments, Payfare, and Pungle. Now he's at EQ Bank, one of Canada's leading fintech sponsor banks.

Braulio joined the bank about two years ago to lead the engineering team through efforts to make the bank even more of a leader in the Canadian fintech space, which we get into in more detail in the podcast. Braulio gives an incredible primer on what to look for when choosing a card issuing processor, what that integration tactically looks like, how to balance speed and agility with the reliability and stability that's central to financial services, and much more.

Braulio Lam:
Reggie, Alli, thanks for having me. Nice to see you again and glad to be in your podcast.

Yeah, great question. EQ Bank, we are one of Canada's leading digital banks. We are a no-fee bank, so we don't charge our customers a fee, and we give high interest rates. I think that is what most Canadians know about EQ Bank. What they don't know about EQ Bank is that we are a 100% cloud-based digital bank. We have zero branches in Canada. We serve our customers entirely online. I think when we launched the digital bank about eight years ago, we were the first Canadian, a Schedule 1 regulated bank to be 100% on the cloud, so we are super proud of that.

Also, we are a fintech-friendly bank. We're a sponsor bank. We have deep expertise in payments and Banking-as-a-Service. We've actually partnered with a number of fintechs to deliver a ton of innovative solutions to Canadians.

Reggie Young:
That's always interesting for me with a legal background to see the differences and how banking is done in different countries. With my nerdy question out of the way, I'll hand it over to Alli.

Alli Nilsen:
Well, I'm not going to be locking nerdy questions either. I feel like my next question is more like a setup for Braulio than anything else because I kind of already know the answer. What were you hired to do at EQ? I know your technical background because you and I worked together on a project five, six years ago. Were you hired for what your t-shirt says, which is to make bank? Help the audience have a better sense of what it is you do.

Braulio Lam:
Yeah, great question. I came to EQ Bank to lead engineering, including payments, but more importantly, to help them drive an agile transformation that was just about to start. Although the digital bank is not very old, only eight years old, we were starting to see the need to change the way we were doing our ways of working, the way we were innovating. Because we want to innovate so much in the Canadian financial industry and we want to stay ahead of our competitors, we needed to ensure that we were scaling our teams, our infrastructure. That was the main reason I was brought in.

Reggie Young:
That's a perfect segue into the next question I want to ask around, how do you tactically enable that sort of agile flexibility within a bank? Again, you’ve got the startup background, not always the same culture as an established bank might have. You want to move fast. You want to be flexible. But also it's a banking system, it's people's money. What have you seen be effective to kind of enable that agile transformation on a tactical level?

Braulio Lam:
Two or three things come to mind. I would say, one, and I mentioned it earlier a little bit, we're doing a deep agile transformation. That, to me, means we're restructuring the way the teams were structured, number one. So we've created these two pizza pots, small teams, very, very much like you would find in any fintech.

The other thing is that we've implemented fast but safe changes. What does that mean? To your question, we're balancing compliance and risk management with our need for speed, if you will. And so we are working very closely with our compliance team, our AML teams, our risk teams in everything we do. We try to include them early in the process as we are attacking each of these initiatives that we have on a quarter-by-quarter basis.

But I think one of the most important things, too, is we focus a lot on providing our teams with the psychological safety that they need to move fast, to be able to make mistakes and not feel like they're going to get their wrist slapped. That is something that is easy to say but a little bit more challenging to implement. But actually, we are seeing a ton of value, I guess. We're seeing the fruits of our labor, introducing that psychological safety that maybe perhaps didn't exist as much as it needed to.

Alli Nilsen:
Yeah, that makes tons of sense. I've never worked at a bank, but I've had it explained to me like, what you put in writing can be audited. What you don't put in writing can be audited. To Reggie's point, you could spend forever just sitting there trying to figure out, am I going to get in trouble? Am I not going to get in trouble? And that absolutely hinders progress. So figuring out the cultural balances of encouraging people, I think, is a really cool perspective.

Braulio Lam:
Absolutely. You know what? When you start peeling the onion of what should be perfect and what can be iterated and made better through feedback loops, you realize that a lot of it doesn't have to be perfect. It's really a small but very important part of the bank that needs to be perfect. Think of AML. Think of risk. But a lot of other things can be done really, really well if we apply an agile iterative process.

Alli Nilsen:
Speaking of implementations, one thing that I love about your history- and quite frankly, I don't know many people who have implemented with as many processors as you have. I know some things about processing having worked at two backend processors now, but I'd almost argue from an outside point of view, you might be one of the leading experts in Canada or the US because you've done so many. One, how many processor integrations have you done now? And two, what makes a good or bad processor, from your perspective?

Braulio Lam:
Thanks, Alli, for the question. I don't like calling myself an expert. I've had a lot of experience, good and bad, but I guess that's a unique opportunity that I've had in my career in payment so far. I think it's five or six processors, from the oldest to some of the newest ones.

What makes a good and a bad processor? Let's start with the good. Personally, as an engineer, the first thing I do is I look at APIs. Show me your API documentation, and I'll tell you who you are. That's the first thing. Is the documentation clear? Do they have user guides? Do they have examples? Are there diagrams? I'm a very visual person. Do they have diagrams for this and for that? That's number one.

The other thing I look at, obviously, are they reliable? Their uptime. Can they support four-nines? Do they have redundant infrastructure? Those are also very key things for somebody like myself to look at. Maybe not for the business or for the payments team, but for somebody like myself, I look at those things.

And then you get into things like compliance, obviously. How efficient are they when it comes to settlements? Obviously, at the end, you're looking at flexible pricing. I’m talking about my experience with processors, but I've seen all kinds of pricey sheets, some processors that charge you for every little thing, others that are able to provide you blended rates for the things that are important to you, and everything in between.

But you'd be surprised how that's still a bit of a challenge, depending on who you talk to. So those are the big things. Before I forget, a very important one that I have seen as key with the processors that I've had a lot of fun working with is their customer support and their partner support. And this is where Alli and I connected a few years ago. We built a great relationship, and it made the project just run so smoothly because you have on the other side a great partner, supporting you, answering your questions, and being there for you. I think that's good.

Alli Nilsen:
Yeah. I appreciate that because, ultimately, yeah, we all come to work every single day and it's going to be a job and how do you make it fun? When I used to do bid implementation projects, beginning of my payments career, and Braulio, you know this, you were one of the first projects I ever had, I used to kick things off by calling everything, welcome to the payments adventure. Because ultimately, something's going to happen that makes it adventurous, however you define that. And being able to work through things with your partners, it does change the outcome of a project, if you can see the issue you're working against as not against each other, but against the problem that you need to tackle.

Braulio Lam:
Totally. I didn't answer the bad side of the equation. Not that we need to call out anybody, but there's still-

Reggie Young:
It's okay, you can name all of our competitors if you want. Go for it.

Braulio Lam:
I'm still surprised about some of the processors that still are around and their systems are just outdated. You can tell from the documentation that comes to you via PDFs, that's a telling sign for their poor developer experience. Nowadays, 2025- when I started my career in engineering, developer experience was poor, to say the least. But 25 years later, we've advanced so much. Developer experience is one of the most important things. So unless you can provide your clients an experience so that the developers can just quickly and easily implement a solution, then you're going to be losing a lot. That is a sign of a bad processor, where your developer experience is poor. We talked about pricing.

This one is also important. The last one that I'll mention is lack of transparency. As an engineering leader, I want to be able not only to see in real time, have access to observability and monitoring and alerts, but I want to have a transparent relationship with my processing partner in the good times and in the bad times. When things are not working well, you need that partner on the other side to be completely transparent so that you guys can work together in a trust environment and get through whatever obstacle you're trying to get through. That also doesn't happen a lot, believe it or not.

Reggie Young:
You need reliability of uptime as well as people on the other side. We talk about it at Lithic, about three core pillars to building good financial infra. You need really good tech, you need really good operations, then you need really good people. And I'd be curious, in choosing an issuer- you spoke a lot to the technical side, but obviously, there's the operational teams that also engage with an issuer a bit once the technical stuff is set up, all the processes and boxes that need to get checked around that from non-technical folks. How do you coach operational folks on what to consider from an engineering perspective when looking at an issuer?

Alli Nilsen:
Yeah, it's not a one-sided decision, ultimately. You have people in operations who have opinions and they're strong about, hey, I care about these things, that aren't reading the API docs. And then you're reading that side and seeing things they might not know to flag as positive or negative. How do you bring both sides of the coin together?

Braulio Lam:
That's a good question. Putting my operations hat on, I would say that, I think what's really important from an operational perspective is making sure that we have, as I mentioned earlier, that transparent relationship with our partner on the other side, making sure that things like reporting is readily available for us as a bank or for a fintech to be able to manage their business. That is super important, settlement reporting, all of that.

I've worked with processors where they were sending our operations team the raw settlement reports from the card networks, and they were expecting us to decipher them. If you have seen raw settlement reports, they're not easy necessarily to read. And so I think things like that are super important. Obviously, from a customer support perspective, especially for us as a bank, we're always talking to our customers. They're always calling us to ask for help. And so being able to get the tools necessary for us to be able to help them is super important.

Reggie Young:
Okay, so let's say you've gone through all of that. You've thought about it from an operations technical perspective. You found a processor that's transparent. You like them. You sign on with them, and now you've got to do the integration. As somebody who's done five of them, what does an actual processor integration look like? What are some of the big pillars of technical work that it entails?

Braulio Lam:
From a technical perspective, I think first and foremost is getting very familiar with the API documentation, making sure that we have SDKs where needed to be able to implement faster. I always like to start with a little POC with the processing partner, create a little proof of concept, make sure that we can communicate. Obviously through that POC, there's a lot of network integrations between the two parties, setting up VPN tunnels and firewalls and all the fun stuff. And then once that's set up, then you can run the POC. And then, obviously, you get down to nitty-gritty and you start implementing APIs on your end.

There's also, I think, something that is very important that often engineering teams don't look at is working with our product design team on what experience we want to offer our end customer, but also sharing that with the processor. I've seen that being super valuable. Because people like yourselves on the other side, yes, you provide the processing capabilities, but I know for a fact that you would appreciate understanding more about the use case, what is the intended experience that you're trying to offer your customers. So actually working with our design teams and working with a processing partner and sharing what that experience is going to look like is key in order to deliver a success.

Once we do that, I think working with our compliance and risk team is also, I wouldn't say number two, but in parallel. As we're running our POC, we're also working with our compliance and risk team to make sure that we fully understand what the AML process that they expect us to follow is our KYC process. Lately, I'm sure in the US, but in Canada, there's been a lot of focus on AML processes and AML in general. Especially, because at least at EQBank, we are now offering solutions to small business clients. AML processes for businesses are different than you would apply to consumer, to retail. I think that's key.

Also then, we're doing the tech. I have my engineering team working on the APIs and building all the fun stuff. We've engaged compliance and risk. The next thing I'll do is engage our settlement team or our finance team, making sure that they can run the reports they need to run, making sure that they can settle and reconcile all the transactions that we're going to be processing, making sure that we don't get a raw VSS file for the card network. I think that's key. Obviously, finance and settlement work very closely with our data team. So building any data pipelines that we need to build in order to be able to then settle and reconcile is very important.

Once we do that, then we make sure that we have all the performance metrics and monitoring and alerting that we need to have in place before we launch to the public, before we start processing transactions for our customers. And that will also include looking at fraud and security, which is not the last thing you do but one of the most important things. In the issuing world, there's a ton of fraud that we need to do everything we can to stay ahead of it.

Alli Nilsen:
Yeah. Thank you.

Braulio Lam:
Yeah, exactly. That's how I always have looked at integrating to a processor.

Alli Nilsen:
I'm going to poke at this a little bit, just because I've seen so many improvements over the years between your test or sandbox environment that you're going to integrate initially with the processor versus production. Obviously, in the sandbox environment, you don't have the network connection stood up. You're not getting settlement reports because it's all contained within that sandbox.

Have you found that there's anything particularly- when people are looking at the APIs or sandbox access to start prepping and getting ready for all those teams you just mentioned, is there something specific they should be aware of, like, hey, you're not going to have XYZ in a sandbox, or you should do extra testing in the sandbox for these categories, versus live production testing where real money is being swiped on cards? I'm going to get your input on that one.

Braulio Lam:
Yeah. I think it's fair to assume that in a sandbox environment, you're not going to get everything that you would normally get in production. I think this is where it's really important to have good API documentation, good user guides. Because as an engineer, you can build a solution based on some assumptions, as long as you understand what those assumptions are, what data is available, what data is not available. But if you know what the data structure will look like, then you can start building mock servers and create mock data to allow you to implement your solution in a sandbox environment. And then once you've built enough, then you move from the sandbox to the QA environment. Then you can do some integration testing and make sure that your assumptions were right or wrong, and tweak before you go to production.

Alli Nilsen:
Nice. Most of your career has been on the engineering side, like reading and all of the different elements of the APIs and how to manage the teams and the agile and all the other favorite corporate jargon words that come to project management in my brain on that topic. Here's my question. You've spent a portion of your career in product when you were at Payfare. That took me a moment. When you were at Payfare in that product, do you feel like having that perspective has really influenced when you went back to the engineering side? And if so, were there any particular lessons you really took with you?

Braulio Lam:
Yeah, great question. That was definitely an interesting journey for me. Those couple of years at Payfare, they were amazing, learned a ton. As an engineer, especially one that has worked in startups his entire career pretty much, at least in my experience, I never really enjoyed the luxury of having a product team. A lot of the times, the engineering team was the product team. And so I like to think that I knew product, I knew how to do product management, to say that I was a product engineer at times. When I had the opportunity to lead product at Payfare, it definitely opened up my eyes, especially working with big clients like DoorDash. I definitely did have to learn quickly and formalize my thinking around product management, which I was able to do luckily.

One of the things that I learned is balancing the business goals, obviously, with our ability to deliver fast. We used a lot of the OKR methodology at Payfare, and actually DoorDash also follows that same methodology. We focused a lot on objectives and key results. We did a lot of experimentation, which was something again that I have- everybody has heard the words A/B testing. Everybody at some point in their career has been part of an A/B test. But to truly do product experimentation, feature experimentation the way big fintechs do it is quite interesting. Doing that, it allows you to drive your key results, your metrics, and move forward the needle, was fascinating to me.

So yeah, having had that experience, leading product with big clients like DoorDash, and now transitioning back to engineering, has been extremely beneficial, especially as we are going through these agile transformation at EQ Bank. I’'ve been able to contribute a little bit when it comes to product engineering here at the bank.

Reggie Young:
What would you tell yourself about thinking bigger earlier and about obsessing over the customer?

Braulio Lam:
Yeah, I would say, think bigger earlier. I think it's really important, and I still do it today. And it's something that I think everybody should always do regardless of what stage in their career they're on, building strong networks, building friendships.

Payments, one thing I've learned in the last 11, 12 years in this industry is that it's such a small community. It's a very small community. And so ensure that you're meeting people, you're going to meetups, you're going to events, and build that network because you never know where one of those people will be able to help you.

And then I would say, obsess about the customer. That's something that I'm new- just recently in the last few years, I've really started doing, is focusing on that customer. As a nerd, as an engineer, I've always focused on the technology, the app, the cloud, but never really put the time needed to really think about, okay, what does the end user want? What do they really need? What are they asking for? As an engineer, that's one of the last things you think about. And so if I could tell any engineer, any founder out there, be customer obsessed. They're the ones that are going to help you drive forward your solution, your app, your company.