Building the World’s Most Deployed EMV Kernels: Lessons from Olivier Chauvineau

Olivier Chauvineau is one of the foremost experts in EMV kernel development, with more Level 2 kernels deployed globally than any other engineer. Over the last two decades, he has led kernel development, certification, and deployment efforts at Mastercard, Amadis, and now Switstack.

From his early days at Mastercard’s Chip Center of Excellence in Belgium, to founding Amadis and delivering certified kernels to major global acquirers and OEMs, Olivier has been deeply involved in every layer of the EMV stack. In this interview, he shares insights from years spent navigating fragmented specifications, evolving compliance requirements, and a tooling ecosystem that was never built with developers in mind.

As co-founder of Switstack, he is on a mission to make EMV infrastructure more modern, developer-friendly, and scalable. We asked Olivier to share some of his insights over the years about the process and challenges of kernel development and certification.

‍

“The EMV ecosystem still relies on tooling that wasn’t designed for developers. Certification was never industrialized—it’s still a craft.”

Q: How many EMV kernels have you helped build and certify over the course of your career?

A: Over the last 15 years, I’ve been involved in building and certifying nearly every EMV Level 2 kernel available—except C-8, which is not on our radar yet.

At Amadis, we were constantly at the certification labs due to the wide range of customers and projects we supported globally, and the number of kernels we maintained. It was a real challenge, especially because Agnos—the framework we used—was originally designed before contactless acceptance (pre-2013). Once payment networks started releasing contactless specs, we had to adapt quickly as NFC acceptance gained momentum. Things became even more complex when debit networks joined in. That’s when qualifying and certifying an EMV stack became a truly Herculean task.

‍

Q: How did you get started in the business and become one of the premier EMV experts in the world?

A: I started my career at Mastercard’s Chip Center of Excellence in Waterloo, Belgium, around 20 years ago, working as a field issues manager. My role involved investigating EMV issues reported by merchants and cardholders during migration periods across different countries. I built a small tool to help accelerate my analysis. It allowed me to spend more time reading EMVCo and Mastercard specs than digging through emails or databases. That was the moment I started thinking: if I had to implement these specifications myself, how would I do it? That curiosity set me on the path to building kernels.

‍

Q: What are some of the criteria that certification labs look for or appreciate during the certification process?

A: The most important thing is to deliver an EMV Level 2 stack that is actually ready for certification. Every provider delivers their stack with a proprietary test environment, and it’s hard for labs to onboard a new terminal and new tools every week.

Labs want to run sessions as efficiently as possible, so it’s frustrating when they receive a stack that isn’t functional or not well documented. They end up spending time analyzing test results just to figure out if the problem is real or not, and then have to juggle scheduling issues. Providers aren’t happy with the delays, and analysts are stuck doing manually - what should have been automated - as fast as they can. Being an EMV analyst is tough—it’s a kind of craft that could have been industrialized a long time ago. But the industry has accepted the current state as normal.

Q: What does a fast kernel look like—and haven’t you built the fastest one?

A: Performance is critical in EMV Level 2. It directly impacts the user experience at the point of acceptance, which was a major pain point during the U.S. EMV migration. To ensure fast transaction times (specifically for contactless transactions), we designed the architecture with a static tag indexation mechanism. This gives us the best possible timing that can be measured during Type Approval (TA).

Q: What are the most frustrating parts of developing kernels?

A: Here are a few of the challenges - though there are many more!

1 The definition of EMV Level 2

Very few payment networks offer comprehensive documentation. It’s hard to interpret what exactly must be implemented, and which responsibilities fall under EMV Level 2 versus the payment application. The boundaries are fuzzy, and each brand models EMV Level 2 differently.

• Some ICS (Implementation Conformance Statement) forms have 4 options; others have 15+.
• Some test plans include randomness, language testing, and even L1 tests; others don’t.
• Some require an actual terminal; others simulate it.

This makes it a jungle to support 15+ kernels. For a company trying to control its own payment stack, the EMV Level 2 component ends up looking like opaque firmware tied to specific hardware, with all the dependency and complexity that comes with it.

2 Misalignment of the specifications

Each brand uses EMV differently to gain a competitive edge. But it becomes a problem when even the EMV fundamentals aren’t respected across specs. Shared components sound efficient, but they can reduce stability and increase manual tests regression volumes when a kernel deviates from the standard —for example, how brands handle EMV application selection, configurations, transaction flow. And, there is a lack of normalization on features shared between brands. For example, data storage could have been specified at the EMVCo level. That competition between brands has not helped developers along the years, and probably slowed the industry on its ability to scale  terminals deployments.

3 Lack of automation

Out of more than 15 kernels, only two provide automated tools for certification.

4 Tooling

The tools available today weren’t built for developers. They were built to run on qualified terminals—not in development environments. You can’t rely on a tool that times out when you’re debugging. And you definitely can’t replay thousands of test cases a day manually to validate changes across 15+ kernels.

‍

“There’s no real value in building a kernel from scratch—EMV Level 2 isn’t a differentiator.”

Q: What’s the value that moka provides to teams that want to own their own L2 stack without building it from scratch?

A: Switstack moka is a synthesis of EMV Level 2 projects developed over the past 15 years. It’s built to open up the in-store payment ecosystem with a pre-certified solution that can be maintained with minimal development investment.

There’s no real value in building a kernel from scratch—EMV Level 2 isn’t a differentiator. Switstack moka is source-available and comes with a fully automated test service, enabling teams to prep for certification quickly. It also includes a unified API that works across all EMV-capable platforms, including COTS (commercial off-the-shelf) devices.

Learn more about switstack moka.

‍