Jakob Kleihues, co‑founder of ENAPI
EV roaming, OCPI, financial clearing, uptime and AI native engineering
Transcript
Cleaned up from a machine transcript. Translations are machine-generated and may contain errors.
Welcome to the Smart Charge by RiDERgy podcast. This is Claudio Geyken, founder and CEO of RiDERgy. This is your show to learn about all things energy management and smart charging innovation for electric vehicles and fleets. Connect to 450 partners and you build 450 handshakes, or you build one. That is the idea behind Inopi, and my guest today is its co-founder, Jacob Clayhus. In 2.5 years, his company has connected more than 1 million charge points, and it did so with a claim that sounds almost provocative.
Connectivity between charge point operators and mobility service providers should be free. The money, he says, is made somewhere else. We talk about where, about what financial clearing really involves, and about how a very small team keeps its infrastructure running at 99.998% of the time. Let's get into it. Right, Jacob, nice that you are here today. How are you? Yeah, thank you so much for the invite. Yeah, I'm a little bit stressed, as you know, I was late. No worries, rushing from the airport, but other than that I'm fine. Thank you so much.
You made it in from the Netherlands today, so I think I didn't have a guest that made it so far in the same day. Yeah, exactly, especially because I'm home in Berlin as you are, so it's strange. But anyways, very good and thank you so much for the invite. Yeah, and great to also know that you are a true Berliner, born here, born and raised, and your parents as well. It's something I didn't know, as I also was raised here in Berlin. Yeah, I grew up in Berlin.
I lived for quite a lot of years in other cities all across Europe - studied in the south of Germany and in Copenhagen, then worked in London for a short time and in Amsterdam. So I kind of know some other places as well, but I'm back in Berlin for quite a lot of years already now and building Inopi from Berlin as well. Yeah, and maybe you can share a little bit more about your background. I also decided to go from Berlin to the south of Germany, funny enough, to study, but I think a lot of Berliners like to stay in Berlin as well.
What was your motivation to go to the south and to study? I mean, this is going back to when I was 18, right? I wonder if I can even recollect why that was. To be honest, I think a very natural "let's go as far away as possible" - and maybe my horizon back then was a little bit Germany-focused, to be honest. But yeah, so I studied at Zeppelin University in Friedrichshafen, on the Lake of Constance exactly, and
I had a great time there. To be honest, I sometimes wonder how much I'm actually applying from what I learned at university or school in general in my normal life, and it's close to zero, but I definitely have my closest friends from that time still, so I very much would do it again. What did you study?
It's like a general studies program between sociology, politics, culture and economics for the first year, and then you focus - and I focused on corporate management and economics. That was essentially my study at the Lake of Constance, and then I went for a pretty standard Master in Business Administration at Copenhagen Business School for my master's.
And obviously in between, a lot of internships at different startups and different companies. I never worked - and we briefly spoke about that just before we started taping here - for a big company, so I essentially don't have any experience with corporates and how it is working for corporates, and that's why I think I'm on an ongoing basis learning a lot about how these organizations work. But in general, yeah, that is essentially what I studied. And what did you do in your past jobs?
As I said, I did a lot of internships in different companies. There was one company that was maybe interesting for this podcast as well - there was a Climate-KIC. I did an internship at Climate-KIC.
That was at the EUREF Campus, where obviously a lot of well-known European and German companies are headquartered by now, but yeah, back then they had a green garage there and they essentially incorporated some startups there, which was very exciting and I was
just part of the team there trying to help founders get things done essentially. That was maybe an interesting first step, but I think the first step that was really relevant for my future career was at Project A Ventures, where I did an internship in 2018. It was very intense, and what I loved about it is
you're talking to people who are excited about what they're doing every day, because you're talking to founders, and I think that was what I had missed in a lot of other positions I held before. That's why I decided - as I was at InnoEnergy, so also the other kick: Climate-KIC was on broader climate topics and InnoEnergy very much on energy - I could also feel the energy of the founders we were supporting, so I can totally relate to the point.
Yeah, exactly. And then I decided, OK, fast-paced environment, I learned a lot, I'm not bored at all and the people around me are not bored, so let's spend some more time here and essentially start working for venture capital funds. And I did that for 4.5 years, so actually quite some time. Always in the earliest stages, so essentially startups that had nothing, or close to nothing - essentially the founders themselves and their commitment to build something big - and trying to figure out: do they have chances to actually make it, right?
Super exciting time. What did you learn, to be able to distinguish that - and maybe that is also relevant today for your being a founder? I mean, it's hard to break it down like that probably, but I think one thing I believe I learned is that a lot of startups - investing into startups is essentially investing into a potential outlier, as in a company that returns significantly more money than any other company in the industry.
So what you want to invest into is something that has the potential to become really, really big, right? And I think what you learn quite quickly is that everyone has a kind of huge incentive to do that based on data and historic performances of other companies, but a lot of these outliers are actually not following the normal path of other startups - because otherwise they wouldn't do something different and therefore wouldn't be an outlier, right?
Maybe that's oversimplifying, but a lot of the most exciting companies I think are built from first principles, without trying to mimic another company. "We are the Airbnb for phone sharing" or something like that, right? How crazy boring, right? I'm trying not to swear. So that was a little bit of what I learned for myself: think for yourself to a certain extent, because most likely if you dare to think for yourself, this can be more successful than if you don't, right?
And I think that was one of the things. The other thing was: it's definitely to some extent about working hard and being able to understand the context, but a lot of starting and scaling a company is also luck and energy, right - how much energy am I able and willing to invest every single day.
And I think that's something we also learned. What I also learned working in venture capital - idea versus execution, which I saw you had a point on; I don't remember if it was in a blog post or in a social media post. Maybe can you elaborate on how you apply it in your day-to-day as well? And then we will come back to how you got the idea, and whether you pivoted from the initial concept at all. Yeah, I'm always surprised how little we actually pivoted, to be honest, but we can totally speak about that.
But yeah, I mean, you spoke about execution, and I think what our view on this as a RiDERgy team would be is: we are the challengers in an industry, right? As a startup you get into this industry, you essentially have no logo, you have no brand, you have no team, and you don't even have capital in the beginning. Essentially the entire world is against you, right? And the one thing that you potentially have is execution, right?
Because you will always be faster, you will always be able to react quicker, and you will always care more than the companies that are so far the incumbents, right? And therefore I mean we face a lot of situations.
For example, these stealth startups that come out of stealth and launch themselves - I never understood this, right, because from our perspective it's all about execution, and I'm happy to share with anyone essentially what we are trying to build here and all of the secrets that we have, right. Because what it comes down to is we need to execute better than everyone else, right? And I see that happening a lot in this industry. For example, we are asked a lot
to sign non-disclosure agreements, which is something we are open to do, and we do have a lot of NDAs - I always need to be careful what names I drop anywhere - but long story short, we never asked any company for an NDA, right, for the same reason: at the end of the day, execution is going to matter, and not who knows what about secrets that you have an idea about or something like that. And what is good execution for you?
Like, if you had to - the first things that come to mind where you say, yeah, this is definitely what we believe is good execution that we foster every day in the team. Yeah, I mean, maybe that sounds a little bit too easy now, but what that is, is focus, right. Knowing what you want to own in the value chain and then being 10x better than everyone else in owning that and building that, right?
And it sounds easy, but in this industry - I mean, we are by now, and we'll probably speak about that later - working with, have contracts with, slash have onboarded in production, like the vast majority of the industry, right? Especially in Europe. And everyone has problems, and we love to hear about them, right, because it's really sometimes surprisingly hard to get good quality feedback on what it is that we could solve for them, right?
And at the same time, we need to say no to 90, 95% of these requests and ideas that we have, to be able to focus on what we actually want to execute on our own, right? And only if we can actually get this focus in can we actually execute in the next step, because then we know what our mission is, right? And so yeah, my easy answer would be focus. And maybe what I would add to that is we have an insane team, right? So this is a team that is remote-first for the engineering team.
And essentially my co-founders and I had like 5 people in mind who we wanted to bring on board when we started, like the day after we signed our first funding round and knew, OK, we can hire some people. We essentially had 5 profiles in mind and 4 of them we onboarded in the meantime. So for us it's like the dream team to a certain extent, and I think that also helps to execute, right, because everyone is pushing in the same direction, and everyone.
Pushes themselves, but also has a goal-oriented way of working together, right? So we can also tell each other, OK, this was not good, right? And so far, yeah, just have a lot of fun working together. I think that's the second thing. So focus and having fun working with great people. Makes sense. No, I can totally relate. And before we deep-dive into Inapi in a sec, how did - I know you worked for Bonnet - how did you get into Bonnet or into the e-mobility industry? What was the path? Yeah.
I mean, Bonnet - maybe for some people who are listening to this they know the brand - Bonnet is a company, I really don't want to lie now, but it's an EMSP that was started, I would think around 2020 or something like that, out of Imperial College London, by two amazing founders, Patrick and Elliott, who literally out of a university project started an EMSP because they said, OK, out there there's no fancy MSPs with a good brand, right?
And I got to know them quite early - I think maybe 4–5 months into their journey - because they applied for funding from the venture capital fund I used to work for, and I hopped on a call with them. Essentially we did the deal, like quite a small investment, and I started working with the team to build the company, right, and in this time I think we spent quite some time together.
They definitely struggled to raise the next round and so on, and we worked a lot to kind of get that done. And then suddenly it's always like a little bit of a catch-up effect, right? Essentially everyone wanted to invest because the company grew quite quickly. They raised money from Lightspeed and Google Ventures, quite well-known and renowned investors, and then Patrick and Elliott asked me to come on board full-time, and that's what I did. I mean, I don't want to get into the details of what happened at Bonnet.
The company was, a little bit later - like 1.5 years later - sold to Over Energy, and today the team works as Overdrive, amazing team as well. But when the acquisition happened, I already knew I wouldn't want to work for a big corporation in the UK, and also I had experienced this connectivity pain they were trying to solve with Inapi firsthand, both from a commercial but also to a certain extent from a technical point of view. And that's why I left and started Inapi.
Yeah, and then maybe let me just set some context, set the scene, so that we're on the same ground. So the connectivity problem, as far as I understand - and please elaborate or correct me if I'm missing something - that you identify is: there are plenty of players around in the industry. We have CPOs, we have MSPs, those are the most important roles I would say. And underneath the CPOs there are CPMSs, so that's the software that CPOs use.
And then there were traditionally roaming hubs that were created to connect those different players. I don't know the exact number of CPOs and MSPs there was and that there is right now, but it's significant. Maybe you can update us if you have them on top of your mind. And so this connectivity layer from traditional hubs - that's what you identify - there are quite a lot of issues with it, or a lot of ways that it can be done better, and that's what Inapi is essentially building, right?
And maybe you can elaborate now with a bit more detail. Yeah, so maybe first of all - because I think as an industry we're not doing this often enough - maybe look at it from a customer point of view, right, like an EV driver point of view. The EV driver wants accurate data about the availability of charge points, right, and then they want to pay the lowest possible price. And that's very much not how public EV charging works today, right? And now we can get into, OK, why is that, right?
And I think you quite quickly arrive at: OK, there's a lot of different companies in this industry. As you already elaborated, there's different roles, right, like CPO, CPMS, EMSP, whatever. There's also fragmented markets, so there's a lot of different CPOs and a lot of different strategic interests in the market. But long story short, these companies need to work together in an efficient way to make this customer experience actually work at scale.
At Bonnet, what we learned quite quickly is this is not working at scale. So we were a very classic EMSP and essentially wanted to connect to all relevant CPOs in Europe. Back then, it was summer 2022, and there were essentially two ways to connect. What I would call legacy roaming hubs - platforms that were pioneers 14, 15 years ago - essentially trying to standardize the communication between CPOs and EMSPs in the market.
When I started in this industry, they still did something like 80% of the integrations, but already only 20% of the transactions, because the big volume integrations - the big EMSP with the big CPO - had already started to go bilateral, build bilateral OCPI integrations. And that's essentially the second option: legacy roaming hubs and bilateral OCPI integrations. At Bonnet, in the beginning, we thought, OK, why not work with the hubs?
The alternative, as I said, was bilateral OCPI integration, so Bonnet started building a lot of bilateral OCPI integrations - I think over 50. What I can recall is that on average around 10 of those were always down, and that was not because of Bonnet. They had amazing tech. The reason was not even technical issues but more operational issues.
Like, something doesn't work, some conflict doesn't work, some tokens weren't synced, some small interpretation of the OCPI protocol implementation didn't work. And then you need the other person on the other side to debug that.
Let's stop there for a second, because I think it might not be so obvious for everyone who isn't a deep IT integrations person. There are two sides to this integration - two systems that need to integrate and two software layers that need to integrate.
There's a protocol - OCPI - and I think there are a couple more, but the hubs are managing those protocols. Correct me if I'm wrong, but OCPI is, let's say, the free independent one. And in it, like in many other protocols - and I think OCPP faces the same issue, where the charger talks to the charge point management system, but that's not really the core focus of this podcast - there is the question of the interpretation and the implementation of the protocol.
If one stakeholder messes things up, that's when things go sideways. Am I correct in putting it this way? Kind of, exactly. So let me give maybe a little bit of a historic breakdown - and I'm definitely going to be wrong in some ways. I've been in this industry for five years, and I think I understand it quite well by now, but back then I had no idea what happened before that.
But long story short, there are these platforms that back then tried to standardize communication, as I said, as pioneers in this industry. And they started
essentially defining protocols to standardize it. So Hubject came up with OICP - maybe there was something before it, but that's what we know. Gireve came up with eMIP, I think e-Clearing came up with OCHP, mainly out of the Netherlands. And I think because my co-founder Dennis Lauman was one of the original authors of OCPI, there was this willingness, especially among charge point operators, to become independent and essentially launch a protocol that is independent of these commercial, non-neutral players.
That's why the EV Roaming Foundation was launched - we are part of the EV Roaming Foundation today, as are a lot of other relevant players in this industry. What the EV Roaming Foundation does is bring people together to define the OCPI standard. The most relevant OCPI versions today are OCPI 2.1.1 and 2.2.1. There is OCPI version 2.3.0, already launched and implemented by very few players - happy to speak about that in detail. But essentially OCPI is the answer of a lot of
CPOs wanting to become independent of proprietary protocols. So that's the core open-source protocol, and obviously the platforms I just mentioned have adopted OCPI by now. From our perspective it very much becomes the standard - not only in Germany or Europe but actually across the world. I read a stat recently that more than 95% of public charge points outside of China actually communicate OCPP data, and the vast majority of those charge points could also use the OCPI protocol.
So that is, I think, the high-level summary of these protocols. And OCPI - to just answer your question - was launched initially with the idea of building bilateral integrations. Now, I think in your initial introduction you already said the markets for charge point operators and EMSPs are fragmented. There are hundreds of players on both of these market sides, and if you would have 3 players on the CPO side and 3 on the EMSP side, it's quite easy: everyone connects with each other and you have 9 integrations.
Now, if you have 500 players on the MSP side and 500 players on the CPO side, then it's 250,000 bilateral integrations. And I think there you already start understanding: OK, these are all integrations that need a handshake, they need to be set up, they need to be tested, and then they need to be maintained. And now we are talking about a lot of different versions of OCPI that are obviously not interoperable with each other. So it gets very, very messy, very, very quickly - let me put it like that.
So I think what the industry faced - to go back to when I entered the industry - was essentially: I believe connectivity should be a commodity, should be a freely available good, but actually it's a constant pain, and so on.
And that's the main reason for us at Bonnet where we had a hard time delivering a really good customer experience, and most of the costs came from that - even indirect costs. For example, customer success costs were created because of exactly these connectivity issues, and that's why I said, OK, there needs to be a better way to do that, and started looking into other industries.
Yeah, it was summer '22 when I reached out to my two co-founders and essentially started thinking about what a model would look like that would bring together the huge advantages of one single integration and, at the same time, good data quality without significant transaction costs. The answer to that is in AI, but I guess we'll get there now. Yeah, let's get into it.
This is a separate segment, but as you mentioned the co-founders - one thing that struck me, also because personally speaking it took me quite some time to find my co-founder - I find that especially finding technical co-founders, as we are both CEOs, is very difficult. And you managed, if I remember correctly, you had like one person in mind.
That you really wanted to co-found the company with, and it turns out that this person said yes, which is quite impressive - or incredible. How did that story go? Can you elaborate on the co-founder matching, which is so important as a foundation for the company? Yeah, so I mean I had experienced the problem. I had negotiated a lot of roaming contracts. I had tried to escalate a lot of problems with connectivity on the commercial side to a certain extent.
But I knew what we wouldn't want to build; it wasn't super obvious to me whether we could even build it the way I had envisioned. So what I did as a very first step was essentially put together a memo - maybe a little old investor mindset, but a memo on what this company would do, like 5 pages or something. I need to search for it again; it's somewhere on my computer. And I essentially sent this to, I think,
four or 5 people. To be honest, I just did cold outreach. I literally looked up on GitHub who wrote the OCPI protocol, and what you find then - I hope I can say these names here - is essentially Olga Vanier, Patrick Rademakers, and Dennis Lauman. Always among the three names that are the godfathers.
I love that - that's probably from one of my pitch decks - the godfathers of OCPI, yeah, exactly. And I actually wanted to speak to all three of them. I spoke to Olga as well, but then Dennis and I met and had a funny, coincidental second meetup in Aachen at an e-clearing event.
And I can just remember we were already both quite excited about the memo, and we essentially used those two days in Aachen to lock ourselves in a room and think about how this could be built and how we could do that. Now, Dennis back then was still a managing partner, I think they called him, at Ihoma - I think one of the leading tech consultancies in the industry. He had built a lot of CPMSs before and had a really talented team there as well, and therefore it wasn't easy for him to drop out.
For me it was quite obvious that I wanted to start this company. So essentially I think we worked for 3–4 months quite intensively next to our day jobs, and then we came to a point where I said, OK, let's try this for 3–4 months. If we haven't raised until end of Q1 '23, then you go back to your job. And that's how we started. I think what a lot of investors always say is that a founding team where the founders don't know each other from daily work, or where they're not friends, is essentially risky.
And we even had this one guy who said no in our first round, where we had a lot of investors who wanted to invest but said no because of exactly those vibes - like that we didn't know each other well enough - and we were considering sending him a Christmas card every year. We work together now because we are so close. So long story short, Dennis is amazing. He's based out of the Netherlands, and that's why I was always 100% clear that we would build this remote first.
We are trying to hire the commercial team in Berlin, but everything else is kind of remote first. But no, it's really like on the first days we trust each other, love each other, and yeah, we've experienced a lot together now, so quite excited about it. Very cool background story as well - I think inspiring for founders out there. And so you said you created the company more or less at the end of 2022.
Right, yeah, so we officially incorporated the company I think January 23, and we had already signed the term sheet - essentially had talked to investors in December 22. So yeah, it was super quick. It was literally two weeks after we started fundraising; we had like five, six term sheets and had to decide. And then raised the very first funding round literally based on a pitch deck, with Project A Ventures and Seedcamp from London.
Yeah, and that was a 2.5 million round, right? And then January 25 was a 7.5 million round. Yes, so I think announced - I think that was more or less discussed in November, December - sorry, no, 2023. Yeah, am I getting this right now? No, 24, of course - this was January 24, sorry. We were one year off the entire time. So January 24 we launched, and in January 24 we also announced our 2.55 million pre-seed round.
And then announced in January 25 our seed round of 7.5 million that we had closed in December 24. So essentially 10 months after we raised our first round, we raised an additional round. Yeah, time flies. And then I read that you had 600,000 charge points connected by the end of 2025, but now I think the most recent post was like 850 already, something like that.
To be honest, no hard feelings because it's moving fast, but when this is coming out I can say that already - we're now announcing a million charge points connected in production. And actually we are already at 1,050,000, so yeah, we're just growing super fast. We've onboarded more than 450 partners since we started. That's, on average if you calculate that across 2.5 years, a little bit more since we started onboarding, roughly 2 per week or something like that, a little bit more.
And that is literally with one team member who's mainly doing that - of course others can help as well, but essentially one person who's more or less full time testing, onboarding and pushing on the technical side, and the rest is widely automated. I think that's one of the reasons why we were able to grow so fast. The timing was perfect when we started: it was literally exactly the time where people were fed up with the legacy roaming hubs.
They ran into issues with building bilateral integrations, and they had an OCPI-ready API, so essentially we could connect them right away without any significant friction. And of course, building 450 handshakes, you come across a lot of - I don't want to judge, but - maybe a little bit weird interpretations and implementations of OCPI. That's the big problem with OCPI: it's essentially implementable in many different ways, let's say like that.
And we've built workarounds, so by now we rarely see implementation times of more than one to two weeks. Maybe that's a stupid question, but as I'm not so deep into that it will be interesting to understand better. So fundamentally the API quality of one of the stakeholders can mess things up. By positioning yourself somehow in between the stakeholders and ensuring that connectivity works well - still, if one stakeholder messes it up, how do you prevent those mess-ups?
Are you able to identify them quicker, or how is your role - so to say - how are you enabling that the mess-ups don't occur? I think the obvious, maybe low-hanging-fruit value proposition we have here is you're not doing 450 handshakes anymore, you're doing one - with RiDERgy - and then you can scale from there essentially without any additional technical overhead.
You just go into our portal, click "I want to send them an offer," send them an offer, and if they accept, your POI data as a CPO gets pushed to the MSP and you can pull the tokens from the EMSP - super straightforward, very little technical overhead. But to answer your question, I think that's important: we play a huge role in harmonizing the OCPI APIs of our partners. OCPI is set up in different modules, and not every single one of those modules is necessary to make a connection work.
So when we started, a lot of our partners, for example, had not implemented the so-called tariffs module yet, so they essentially had a hard time automatically communicating the tariffs with each other. This creates friction, and therefore what we always kind of motivate everyone to do is to actually implement the entire OCPI protocol. Having said that, I think we play a huge role in harmonizing in that sense that a lot of EMSPs tell us that they have significantly better success rates within NAP than they have in bilateral OCPI integrations.
And I think that's counterintuitive, right? A lot of people in the industry are like, ah, but I'm adding an additional stakeholder in the chain, like it's going to create more friction, there's another party - but this is just not how it works in reality. We have a very sophisticated alerting system, more than 90% of our customer success interactions are outbound and not inbound. So we actually are the ones cleaning up the data and helping partners to get on top of their shit.
And as a next step, we therefore see a lot of very successful transactions. Another issue that you see a lot in bilateral integrations is, for example, sync jobs failing. Some token doesn't arrive at the CPO and therefore it cannot authorize the session when the token tries to charge there, or some EVSE somehow isn't in the mobile application of an EMSP, and you wonder why.
What we help partners to do is to get visibility into the success of their sync jobs, and to get flexibility into how they want to sync - do they want to push or pull the data, when do they want to do this, what is the cadence, and so on. All of these things help the entire industry to streamline connectivity. And I think why I'm putting so much emphasis on this is: NAP from day one wasn't built to replace the legacy hubs.
We are growing also in part because people are migrating from them, but our most direct competition is not these legacy hubs. Our most direct competition is bilateral OCPI integrations, because that's where the big volumes are, and our ambition is that 100% of the volumes of one specific CPO or EMSP are migrated over. Now obviously I know this is going to take time and a lot of trust in the industry. But this is what we're here for, and that's how we have built NAP from day one.
So it's super important for us that, for example, success rates for NAP integrations are higher than in a bilateral setup, and that people understand that this is actually the new normal going forward. And what is also super important for us is that we see the first bilateral integrations being migrated to NAP - it's one thing to onboard all of the logos, but it's another thing to make them migrate all of the integrations to NAP, and we're getting there right now. So yeah.
And one stakeholder or connection type that we haven't talked about, that I think is quite common in the industry, is the platforms - which I think are mostly the backends, the CPMSs - that are also facilitating integrations. So how do you look at that stakeholder type, and maybe you're even able to say which share of the integrations is done via platforms and which one is done via bilateral roaming hubs and now in NAP? That's a good question. No, if it's difficult, I know sometimes I'm just getting ahead of myself.
What comes into my head when thinking about that is our pitch deck for the pre-seed round in January '24. That was essentially where we did a little bit of a customer segmentation, and we essentially said the charge point operator side - the supply side, if you want, in our model - can be separated into three different groups of companies.
The first one is strategic multinational players: oil and gas companies, utilities, car manufacturers, OEMs - essentially companies that have a strategic interest in this market, that have very deep pockets and tend to be slightly slow-moving, although we love all of them who are working with us. The second bucket is essentially the most capable players probably in the industry today, and that is the infrastructure fund-backed joint ventures and startups in this industry.
They are really good at leveraging their data, they are really interested in optimizing their processes. Good examples of that are the Charging League, Fastned, Atlante, Ionity, Electra, Power Dot - those kind of players come to mind.
These players tend to not have the biggest networks, but they have a lot of transactions because they are really high-quality networks, and because they are scaling really fast. And then the last bucket I think is the long tail being aggregated through charge point management systems. So exactly - and how that looks like is.
These charge point management systems act as the contractual partner with EMSPs, so for us they are the CPO, if you want to think of it like that, because they have the roaming contracts with the EMSP and they essentially invoice the MSPs as well and distribute the money between the CPOs afterwards. So for us, the stakeholder or the player we are integrated with is the charge point management system. They also have the account with NRP if they are the contractual partner for the MSP.
So what we always look for is: we really don't care who you are essentially. Are you the party in the roaming contract? And if you are, you are our customer. We work with a lot of CPMSs - we have partnerships announced with more or less all of them by now, we're very close with them. I don't want to lie, but I think there's no CPMS that we don't have any integration with in Europe. Obviously, the CPMSs you can again segment into a little bit older, a little bit slower-moving startups and so on.
I don't want to do that now because, as I said, we work with all of them, but there's a lot of amazing technology and a lot of amazing companies and people that we're working with there. And essentially, if I understand correctly, when you talk about integrating between CPOs and MSPs, you're integrating the CPMS implementation of OCPI, right? Exactly. I mean, the CPOs have their end in complexity. There are CPOs who build their own CPMS - there was a little bit of a trend maybe two or three years ago.
Then there are CPMSs who are just charge point management systems, so essentially software-as-a-service companies, and they don't own the roaming contracts, never. From our perspective, oftentimes in the interests of the CPO, then there are some CPMSs who essentially have a long history in doing the entire financial clearing and the entire heavy lifting for their CPO customers. And all of them have a right to exist.
So it's really complex, but you're right - after all, we have technical integrations and therefore we connect to charge point management systems. But as I said, there are very big charge point operators who have their own charge point management system, and there are very small charge point operators who also have their own charge point management system, so this market has all different flavors. And talking about the business model, I think you already hinted at it: connectivity should be free.
So I understand this is also a fundamental difference between EAI or other stakeholders trying to do the same thing that EAI does, where connectivity is not free. And I understand your business model is entirely based on the financial clearing. Maybe you can elaborate on this clearing aspect and how you do it better than other stakeholders that are focusing on the clearing aspects.
I think I hinted briefly towards this: from day one - and that's also where I'm always surprised that we haven't really changed our identity and mission since day one - from day one, our ambition was to replace bilateral direct integrations, direct OCPI integrations, because they didn't work at scale for us at Bonnet. Some people tell us they work, some people say they don't work at all.
But long story short, if you look at success rates and everything involved, connectivity should be a commodity. And it's not a commodity today, because everyone has a tech team sitting there controlling data, everyone builds their own slightly scrappy validations in-house, they need to look at charge detail records and essentially build relevant transaction data to analyse - and all of this doesn't work.
And we always said we want to build product for 100% of the volumes of a CPO or EMSP, not for the long tail. And if you say that, you need to look at why they broker 80% of their transactions through bilateral integrations. For us, the reason is quite obvious: significant transaction costs. If you charge transaction costs for connectivity, then people have an incentive to go bilateral. Because even if you only charge 5 cents a session -
- at 1 million charging transactions a month, there's quite an obvious significant incentive to go bilateral. And therefore, from our perspective, in a mass market in the future, there won't be any connectivity costs. No one who charges for connectivity will be able to win in the future. I think this was a little bit surprising to the market 2.5 or 3 years ago when we started, but by now the vast majority of the market agrees with us on that.
And then the obvious question is: how do we do connectivity, because, as already stated, bilateral integrations don't scale? So how do we do connectivity, and what is the next biggest problem? I think our answer to that is: let us commoditize connectivity, make it a freely available good, make sure that everyone who invests even one engineering hour into internal connectivity that they wouldn't need to invest is essentially wasting time and money - because they should be investing into something where they can build differentiation.
It's a commodity, it's free of charge, right? And then let's look at the next biggest problem, and from our perspective, the next biggest problem is financial clearing. CPOs have a very hard time essentially getting paid, and EMSPs have a very hard time validating charge detail records, opening relevant transaction data, then approving invoices and paying them in a scalable way, right? The biggest EMSPs out there, they receive like 450 invoices every month, right?
And actually not every month, but every 2, 4, 6, 8, 12 weeks, sometimes with CDRs, without CDRs, different currencies, different VAT rates. It's messy, and this is what we are tackling here. Now, why do we have an unfair advantage to solve that? We only have an unfair advantage to solve that if we actually broker the transaction, right? Because what we can do is we can validate the transaction at a different level than horizontal players who are doing this in many different industries could, right? Because we can look at the charge detail records that are invoiced and can say:
hey, there are some CDRs on there where we didn't authorize the session, this didn't happen - or we can say, hey, there are some missing CDRs, or there are some duplicate CDRs with different CDR IDs, but we know that because we authorized the session, right? And there are millions of details we can validate, but long story short, only because we broker the transaction can we actually build the best financial clearing product out there. Our strong belief is that the vast majority of the market
won't be doing their financial clearing themselves in the future. Right now it's scrappy, in-house processes based on CSV files and so on that we are competing against with our financial clearing product. But in the future this is going to get more complex because we'll have variable pricing, we'll have discounts - there are a lot of things that add complexity to this.
And it doesn't make sense that 450 companies in Europe build their own solution in-house, right, and this is where we come in. So the clearing is mostly done in-house, or there are third parties doing it with, let's say, legacy tech - that would be the
- I don't want to be so judgy about legacy tech, but what I can say is, as always, and I think that's a steady theme throughout our talk so far, obviously there's everything in this industry: people who do it themselves, people who do it with some random companies from outside, people who just don't do it at all and essentially pay invoices however they come and don't validate anything, right?
So there's really everything - we've come across everything. But it's definitely an obvious problem that everyone faces, and you can talk to every CPO and EMSP out there, they'll agree that the validation of billing-relevant transaction data, then the approval of payments, and then the payments themselves are super manual processes.
Yeah, I can confirm as well from conversations I've had. And you mentioned an impressive KPI: 99.998% uptime and under 20 milliseconds latency in 2025, which is quite impressive. How are you able to achieve such great KPIs? I understand that's what you are competing against legacy tech with - strong arguments to be made to adopt your technology. Yeah, so I think what is very much true and an easy argument is an insanely talented team, right?
We are still a very small team, and we are very conscious about that, right? We believe that if we're an intermediary and we don't want to charge connectivity costs, we can build this with a very lightweight team. At the same time, we have incredible talent on the team. The other honest answer is, in contrast to the legacy hubs I just spoke about, right,
we didn't start 14 years ago - we started in 2024. Our cloud infrastructure is probably the heart of our product; it's state-of-the-art technology, and that's how we can achieve that. Also, one thing I want to share is that, in contrast to most of the players out there, we actually publish our uptime at all times, so everyone can go to status.api.com and see the uptime of our infrastructure both in the US and in Europe.
We hold ourselves accountable by making this public, and so far this has been working really well. Super happy with the team, and I think there are many reasons for that - there is a lot of work involved, to be honest. And also a lot of AI. As it's the name of the game, it's on my mind every day. How are you looking at AI as, probably, an AI-native company?
So, first of all, yes, right. I think - I wouldn't need to look it up again - but I believe since around January 15th or 16th, 2026, when a new model of Claude was launched - Sonnet, was it? Yeah, something like that. Anyway, I think more than 94% of our production code was AI-written. Obviously it sped us up like crazy, and definitely this helps, right?
What I will also say though is: we are not your next kind of AI rocket ship company that just throws whatever comes their way into a pull request and lets go, right? And there's a very good reason for that. If you essentially want to build trust with big corporations as a company, as a startup, the one thing that they will look for is: is this product working, right?
And you just cannot afford, if you are infrastructure-relevant for CPOs and ESPs and that is direct ROI-relevant, to be down for 20 minutes or an hour like the legacy hubs sometimes are. This is just something we cannot afford as a startup. And therefore there are parts of our product - and our engineers are very aware of that - that we only touch with utmost care, and where AI is helpful but obviously not kind of replacing the really important second, third and fourth look from humans, right?
So that's the one comment, but yeah, AI is definitely a huge topic for us, obviously enabling us. And then, maybe last but not least, on the commercial side - it's crazy, right? I mean, today one of my co-founders spends a lot of time in product, but he's also quite involved with customers. But other than that, it's me and our newly hired Director of Growth, Dennis Daniel Brown, from former ChargePoint.
He is handling our commercial scaling. So by now we work with the vast majority of the industry, but we haven't run crazy outbound campaigns to reach them, because it just doesn't work. I was more or less alone on the commercial side, and AI helps a lot. So that's another dimension. But with that - whoever has never talked to me in the past, please reach out, especially CPOs and MSPs.
We are sometimes surprised by some of the players, especially in the Spanish region, France, but also in the Nordics, who have never heard of us and are a little like, "ah, OK, this sounds interesting" - and we're like, yeah, alright, let's talk. So yeah, I'd love to talk. And you said in the past that there's a problem with collaboration in the industry, that you feel like we should collaborate more. What did you mean by that?
To be honest, I don't know in what context I said that. I'm sometimes surprised by how open people are for collaboration, but I think there are very few alternatives for us. Most companies are not like Tesla, which essentially has a full-stack solution from hardware to charge point operator to CPMS to EMSP to essentially a car, plug and charger, and so on. There's only Tesla, essentially. And other than that, people have to collaborate and cooperate, so I don't think it's really an option not to.
So yeah, not sure when I said that, but I agree - as much collaboration as possible is helpful for the industry, I think. And then there was a post you made, and maybe you can elaborate in your own words again: it's "size of the pie over slice of the pie," if you remember your blog post. Yeah, so from our perspective - and to be honest, I can feel this in the vast majority of the conversations I have - if the industry wins, everyone wins. And that is our mindset. We're not trying to kill a competitor. Diesel is the enemy.
Yeah, exactly. Diesel is the enemy. The Tankerkarte is the enemy in Germany. At the end of the day we want to play a role in enabling the green mobility revolution, and we're just not there yet. I mean, 17% growth sounds good for an old-school industry, but what the hell - we need to make this transformation work.
And if the entire industry is focused on that, we'll make it work much quicker and everyone will benefit from that. That is what I mean by that. We are not optimizing to, I don't know, kill another company or capture some specific percentage - we just want to make sure that we actually solve connectivity for the industry to help it scale.
And I think so far this mindset has helped us quite a lot to do the right things. That often makes sense. And then let's talk pricing, which is a topic I'm also particularly interested in in the smart charging and flexibility space, which will come as a last bit. You also wrote about it - that there are different levers that CPOs could play: volume incentives, fleet rates, and other types of surcharges on traffic routes to aggregators.
Maybe you can elaborate what your view is on the future of pricing, which right now - everybody probably knows - is still quite static. It's mostly dependent on charging speed; if it's a DC charger it's usually higher, but not too many dynamic rates. Where do you see the industry going? And maybe also, as a segue to flexibility, what would the ideal pricing look like, if you have any thoughts on that?
I recently heard a static - and a talk, or the Museum talk about the transportation ministry, or whatever it's called - talk about flexibility. This would be exciting, I imagine, right? And I had a little bit of this kind of Angela Merkel "internet" kind of remembrance. I don't know if you know what I mean, but essentially, for us it's quite obvious, right? I read a stat - I need to look this up again - but something like 75% of the battery capacity until 2030 is electric cars driving around, right?
How can we actually lift this potential, right? Lift this treasure. And I think a lot of very smart people, you included, essentially spend a lot of time on this question, right? We are starting, and I think I'm coming back a little bit to this focus point, right? We could now be thinking a lot about how do we implement that, how can we orchestrate that, whatever, right. This is not where I'm spending my time right now. Where we are spending our time is: how can we help
companies that we are working with to run the business model that they want to run, because otherwise they again will have an incentive to go bilateral if they cannot do what they want to do, right? And a lot of them want to test out a lot of things. I think this starts with variable prices, right? I mean, a very easy start would be two different prices a day, nighttime pricing, da da da - this can be communicated through the tariff module, as I said, the first challenge, right, that we need to help
But then, obviously, what we also see is, for example, for heavy-duty vehicles, quite a lot of discounts, because it's quite attractive for CPOs, right? So how do you implement these discounts? Because it gets really messy - what we see in the industry a lot is charging operators just applying a 10% discount to the invoice. But then once the CDR is kind of challenged, suddenly the whole thing kind of breaks, obviously, right?
So you want to get this to the OCPI level, and to the charge detail record level, to be able to really have control, right? And that's what we're enabling for a lot of companies. So what we have in place today is what we call discounts - I can also theoretically add a surplus - but essentially what we do there is we enable CPOs to define a discount for a given partner, right?
Our system then re-rates the tariff module, adds a routing header to the tariff module for the specific partner that they want to give a discount to, and then also re-rates the CDRs, so that the EMSP receives the correctly rated CDRs from them. This is a product we natively support today, and it's quite an exciting product potentially. But I think, to go over to your next question, this is a little bit more fancy thinking.
I mean, I always feel like what sounds good is essentially: how do we implement an incentive scheme via a price mechanism from the energy provider, throughout the chain to the EV driver, right? With obviously the goal that the EV driver reacts to the price signal.
And I think this is future music where we are happy to play a role, but right now our clear focus is on enabling our partners. One could say you enable it through better implementation of connectivity of CPOs and implementation of certain modules like the pricing module in a better way - this also is the foundation, at the end of the day, for fancier stuff if you want. 100% agreed, right? It's a little bit like if you go to the US, for example - it's a super exciting market, there are a lot of super interesting people who we are working with there right now, right?
Like, when everyone is talking about autonomous driving - and we agree, obviously, right - but our focus mindset is always: OK, but what about making the charging transaction today work, right? And I think by thinking like that we actually get to enable that, so I couldn't agree more. Yeah, by the way, I saw your trip to the US, which was quite recent as well, and you also mentioned autonomous driving being a big part of the trip as well.
So you are active already in the US as a solution right now. Is there - you also said that there are quite a lot of differences - but for you as a product, would you say there is a big difference now to operate in the US compared to Europe? Yeah, our product is theoretically scalable
across the world today, right. OCPP is a standard, and then OCPI is to a certain extent a standard as well, and we have launched a North American infrastructure and we are actively onboarding partners right now. It's still early, but we already have signed - I don't want to lie about it - I think it's something like 13 contracts now and onboarded like 8 partners or something like that.
We have brought on board a person I always wanted to work with, Daniel Brown, former global head of roaming at ChargePoint, and he's leading our US efforts as well as the UK efforts. He was recently there. I was there quite a lot because we also raised our seed round from a US venture capital fund - Voyager Ventures exactly, probably the leading
They always don't want me to say transatlantic, but the leading climate VC - I think now they don't want to call it climate anymore, now it's resilience or something like that - but anyway, I think I'm part of the community. They're amazing people who understand electricity and electrons better than anyone else I've met, and who are exactly as the other two VCs that are invested in us interested in financial return.
What I want to say about that is we don't have any strategic investors, right? So there's no one who will tell me, "Hey Jacob, can you please build this and that because this big company would want that." And that's so important for us to be neutral and to be solely focused on financial return. They're amazing, and that's why I spend a lot of time in the US. We like it a lot in the US. It's different, but I think our product is kind of scalable right away.
I think the main difference - and this is an interesting one - is we don't want to force anyone, also not in Europe. The very idea of an AP is you own your own contracts and commercials and therefore you have control. In the US that argument is even more important because no one wants to be forced into roaming or anything like that.
We believe that to optimize your utilization and your unit economics, it's a good idea to work with other partners - but we give you the infrastructure if you want it, and you keep control. That's very important in the US, and that's something we learned. And I think it's going really well. So you're open for business everywhere in the world right now? You're taking me at a good one, because I speak a lot about focus and the honest answer is probably yes.
There's a world where we say no to some things that are really out of our scope right now. But maybe to take a step back and think about our growth patterns: a lot of startups have a city-to-city, country-to-country, region-to-region, currency-to-currency growth pattern. That's not how we grow. We grow network to network, and if Ionity, with charge points in 24 countries, tells me, "Hey Jacob, can you please onboard these five EMSPs in the new country that I'm entering?"
Obviously I'm doing it. So that's the nature of it, and that's also what brought us to onboarding partners in the US, but also to onboarding partners in Australia, New Zealand, and other regions.
So it's a careful - it's a yes - and let's keep the focus. Yesterday I was at a conference where one leading topic was electric trucks, at the national Leitstelle - the electric mobility association linked to the government - so electric trucks are quite a hot topic right now.
Does it affect your business in some way, like booking or MCS? Yeah, so we have a feature for example that we call OCPI version interoperability, where we enable different partners to be connected to us via OCPI 2.2.1 and then roam with partners who are on 2.1.1. That is quite helpful for some partners who are still stuck with 2.1.1. Now there's a new version of OCPI, and I'm not the OCPI expert - out of our roughly 20 team members, probably
11 know it better than me, maybe even 15. But what I can say is OCPI 2.3.0 essentially has two main features driving adoption from our experience so far. On the one hand, in the locations module you have more ability to communicate more sophisticated data - for example, how big is the charging lot and things like that. And secondly, the booking module. The booking module is essentially an add-on that lets you book a slot in the future.
We believe that is highly relevant for logistics companies and especially relevant for behind-the-fence charging situations. But in public charging, at least a lot of the people I've discussed it with tell me they don't really believe in it at scale, because there are potential operational issues that arise - for example, there's another car parked there right now, so what do we do?
Those kinds of things make it quite complex to deliver a really good customer experience around booking sometimes. We're part of the EVRoaming Foundation, we're fans of the new protocol - don't get me wrong - but what I'm saying is we don't spend a lot of time on booking, and for public charging, where today our focus is, we don't feel like it's top of mind right now. Heavy duty vehicles, though, are totally top of mind, and we have onboarded the core players in the field.
I don't want to name names now, but both on the EMSP and CPO sides I think we have all of the players connected, and we're happy for them to roam through us. Why is it interesting? Because of crazy volumes, and because trucks are always driving and therefore also need to charge a lot.
So maybe last comment on that: when I entered the industry 5 years ago, there was still a lot of players in this industry running around saying, "Yeah, hydrogen - for passenger cars maybe electric is now going to be the new normal, but hydrogen for trucks I'm pretty sure." And Bavaria was kind of funding some hydrogen ideas around mobility with 200 million or whatever, right?
And it's just quite funny sometimes to take a step back and look at this again and see how this industry is now so obviously going for electrification as well. And maybe, I mean, for us that is the reason why it's sometimes frustrating to discuss things like - I don't know - we have these buzzwords in German politics like "Technologieoffenheit," openness for technology, and you're just like...
Yeah, alright, we can keep this open and kind of lose even more ground than we already have, because it's so obvious from first principles that electric mobility is going to win. And again, that's one of the big messages I want to put out there: size of the pie rather than slice of the pie. Please, let's all understand there's no alternative and it's also not going to change. Let's go. And there are a lot of people in Germany and Europe who haven't understood this.
Yeah, and just looking at the future - the last question before we end on a personal note - bidirectional charging: do you see it in public charging or only in private charging? And now that you focus clearly on public charging, do you see a big role for iapi also in private charging?
Yes, focus, right. I don't think about it too much - well, I do obviously. I can just tell you what I hear from our talks with C-levels at more or less all relevant CPOs out there, and I think they're thinking about it quite actively, also for public charge points. And that's interesting for me to hear, because obviously their identity is selling electrons, right?
And now suddenly they're going into, "OK, we're not optimizing utilization, we're actually kind of trading flexibility" - and it's like, OK, there are some open questions there, right? How this is going to be implemented, we don't know, but we do believe it's at least something that public CPOs spend time with. And for your question...
I think for a lot of these connectivity topics, we are their preferred partner to talk to, and we are very happy to discuss with them how to implement certain ideas. And for private charging - yeah, of course. We already have a lot of private charge points connected. We know that roaming is obviously a topic for private as well, and we believe that we are quite obviously the best solution out there for connectivity today, and that's both for public and private, right?
Why am I not talking about it a lot, and why am I not reaching out to CPMSs who are focused on private charge points and behind-the-fence charge points right now? Focus, right. I can't do everything, and I think we want to leverage network effects. We very clearly see these network effects in public EV charging right now, and we want to leverage on that. Alright.
And I don't know if you actually drive an electric vehicle, but if you had to share a funny, or also a bad, public charging story - and maybe one very pleasant one? OK, that's a good question. So first of all, I currently don't have a car, but actually I have two electric cars in Berlin available to me. My dad drives a Honda, my brother drives a Tesla, and I've obviously used both of these cars a lot for charging transactions. I think the most delightful one to break it down is...
Yeah, what is it called - essentially a trip that we did at one of our on-sites in Berlin, where most of our team members came to Berlin. Our new team member Daniel Brown essentially did a tour with us through Berlin from ChargePoint to ChargePoint, and obviously our engineers took their computers with them and tracked everything a little bit, and that was fun. That was very nice - two cars, eight people, just enjoying themselves. And then, do I have a bad story? To be honest, I obviously hear about bad stories everywhere, right?
I mean, I tell my family, or friends of my family, or my parents, or investors - I tell them connectivity doesn't really work, and more or less, I would say 90% of the people I tell this to say, "Yeah, that's true. I was on holiday once somewhere, I had an electric car, and it was really awful." And I heard like 20 of these stories more or less in the last two weeks again. So yeah, I'm looking forward to fixing it, but I don't want to add more stories.
Well then, with that, we end on a good positive note - you're doing your best to fix it very quickly, I'm sure. Thanks a lot, Jago, for your hard work and for being here today. Thank you so much. Thanks for the invite. Three things stay with me from this conversation. First, the price of connectivity. Even a fee of 5 cents per session adds up at 1 million sessions a month, and that gives partners every reason to build their own direct connections instead. Jacob's conclusion: no one who charges for connectivity will win in the long run. Second, clearing.
Because Enapi brokers the transaction itself, it can compare invoiced charge detail records with the sessions it actually authorized and find duplicates or missing records. Third, AI. More than 94% of Enapi's production code is now written with AI, yet the parts that cannot go down are touched only with utmost care, and the uptime is public for anyone to check. Jacob's word for all of it is focus. Thank you for listening to Smart Charge by RiDERgy. If this episode was useful, share it with someone who works on charging infrastructure, or give us a 5-star review. See you next time.
Episode notes
With 500 players on each side of the market, connecting everyone to everyone takes 250,000 bilateral integrations, and every one of them needs a handshake, testing and maintenance. Jakob Kleihues, co-founder of ENAPI, argues that connectivity between charge point operators and mobility service providers should be a free commodity, and that the real money is in financial clearing. Jakob explains why connecting to hundreds of partners one by one does not scale: with 500 players on each side of the market, that is 250,000 bilateral integrations, and every one of them needs a handshake, testing and maintenance. ENAPI replaces them with a single connection. Since it started onboarding, it has connected more than 450 partners and over one million charge points, with implementation times that rarely exceed one or two weeks. He also shows why even a fee of five cents per session pushes volume towards direct connections, and how brokering the transaction lets ENAPI check invoiced charge detail records against the sessions it authorized. The conversation also covers the practical side of pricing, from discounts applied at charge detail record level instead of a flat reduction on the invoice to the new booking module in OCPI 2.3, and what it takes to keep a published 99.998 percent uptime with a very small team where more than 94 percent of production code is written by AI. Jakob explains why the US, Australia and New Zealand followed network by network rather than country by country, and why he wants the industry to think about the size of the pie rather than the slice. An episode about turning connectivity into a commodity, and about what it takes to make public charging simply work. Topics covered: - OCPI and why bilateral integrations do not scale - Free connectivity and the business case for financial clearing - Validating charge detail records - Discounts, variable prices and the booking module - Uptime and AI native engineering - Growing network by network into the US