Fraude in E-Mobility [2/3] met Last Mile Solutions

[Music] Well, hello everybody, we're on the LabPost 10 podcast again and as you know this my language has changed a bit. We're not talking Dutch anymore but in English today because we have international guests on our table. We're broadcasting live from No Not Live but it's really fun to say we're broadcasting live from Rotterdam from the main office of last mile solutions with my co-host Peter from Zylin. Hello. Hello Peter and our guest Matthew Lapsley and Danzel Nagen. Matthew is representing Plug Surfing as MP and Danzel is representing Road/Eflux and we're both discussing today about fraud in immobility and then from the perspective of the EMP. So that's about it. Peter can you introduce a bit yourself and what are we going to do today? Yes, I'm Peter. I'm a fraud director at Last Mile Solutions and we're a wide label platform provider where we have quite a lot of chargement operators. We also have quite a lot of immobility service providers on our network and yeah we had of course a podcast about the CBOs last time and now we're really going to focus on EMPs and it's actually the EMPs piece of the immobility service providers. Those are the ones who actually issue cards or have typically the end user accounts with them. They're often victim of fraud and it also has to do with the fact that that well in immobility we typically see that you represent the end user. The end user takes the electricity and then you have to pay the CBO regardless whether you get paid yes or no by the by your end user and so many EMPs piece well have quite a lot of experience with fraud some quite massive and I think maybe the last time we also found out we actually asked quite a lot of companies to talk about this. We're quite happy that EFLOX and that looks like we're taking this serious. Yeah absolutely. Others are also taking it serious but they just are not open to discuss this publicly. Yeah it's quite sensitive topic right there. It's very sensitive. It's about a lot of money that's the things and yeah if you lose a couple of million per year as a company then you're typically not screaming that from the roof. What you know what really interesting is about that I was just figuring if an company makes millions then everybody is screaming yeah we're making millions but if a company loses millions which is evenly important I would say then everybody is like losing millions. Yeah but it has to be with the fact that we discussed this quite often and I always say this as well it's the balance between user interaction and how do you prohibit fraud? There are quite a lot of companies that more or less say okay well it's fine fraud we just pay off the 100,000 per month because yeah we just want to have the user interaction that's really fine and nice. It's part of the deal right? It's part of the deal that they just calculated in and and they also that's don't forget that. We all know how how easy it sometimes is to commit fraud at certain points and not only here but also if you go to the supermarket which are not you don't want to bring people to ideas that's really why you don't want to do. Okay so let's not bring people to ideas then. No that's yeah yeah so let's not bring it in complete detail how you could do it in each of our companies but yeah it's something that a lot of companies say okay let's not talk about it's not happening to us. Yeah. Some are actually also in denial they don't even know that they have fraud. Okay this is a nice bridge met you are you in denial? Certainly not. All right introduce yourself a bit. Yeah thanks and then our relic theory is about you being in denial or not. Yeah and for firstly thanks for inviting me to Rotten Entertainment. I'm a product manager at Plug Surfing responsible for the revenue team which is mainly back office features pricing clearing at CPO and voice validation of course fraud. Plug surfing we we are very much EMSP service provider so we have our network we manage the network the operational challenges with that the risks but we offer that to our customers who can then focus on their core business and managing the drivers. We offer that network to lead management companies OEMs and most recently CPOs that are wishing to extend their own core network with us which with our extended roaming network and what's very important today to point out from Plug Surfing's perspective is that the majority of our sessions are actually cleared externally meaning we're not actually responsible for the payment process for the majority of our sessions which is a key point today. Thanks for the significantly more challenging and our customers of course expect us to manage E-mobility fraud not fraud in general but E-mobility fraud on their behalf. Do you feel like that's an impossible task for 80% of your transactions to not be able to to to clear them yourselves and so on. No but it means that you can't look at fraud purely from non-payments you have to look at fraud from many different other aspects which I'm sure we'll we'll cover today. Okay yeah that makes it a lot more difficult again imagine. No I think both are needed regardless you know you don't want to wait until the point of payment to understand that that fraud especially I mean when you get into post payment you can't be having unlimited credit limit for 30 days and then 15 days for payment times and then discovering you have a problem so yeah so fraud starts from the point of authorization from from our perspective. Okay that's interesting how does the dancer welcome. Thank you. Could you elaborate a bit on the more on that after your introduction? Yeah sure so my name is Devinzel thank you for having me. It's quite a nice little topic to talk about it's been something that I've always dealt with in terms of fraud so I wasn't talcob before and was part of the fraud and revenue assurance management team there and of course now when it came into EV I found that this is actually quite an interest in topic as to how it's actually coming together but just maybe a little bit about what we do as road we of course have our own e-flux offering which is a MSP where we offer customers there a charge card and allow them to go and charge to their actual network itself but we also provide white label solutions for MSPs and CPS and of course we do operate as a CPS ourselves so our MSPs are expecting us to have solutions to fight against all of these fraud situations so of course we use ourselves as a the gold standard that we want to get to to making sure that we eliminate fraud completely. Okay do you think fraud is more a topic on the CPS side or more than EMP side? Definitely both and I think it's switching around but actually get to more real time payments CPS now have to offer payments directly so that brings in a whole different level of fraud now so it's definitely across the board of course also you have the reimbursements like you mentioned you know when that comes into play then you have a little bit of a you like a ripe for money laundering within the organization so it's it's very new and I think it'll get a little bit worse at some point in time so it's going to be. That's a nice cycle then. Yeah well we need to stop it as before it even happens. I think that's also one of the reasons why we do this podcast is okay wake up everybody in our industry like okay because there are quite a lot of companies still quite sleeping on this topic like wake up you need to do something and it's really great to see because we're actually more or less competitors we all offer white label solutions that we actually talk about this that's something that we do in this industry quite often where we talk about it even people that don't want to publicly talk about this we still talk with them because we actually all have the same problems. Yeah do you think many companies are in denial still? Yeah as I said I think there two years ago there were definitely large companies that were in denial I actually heard that in one of the meetings yeah big company I cannot name it of course but it would actually yeah we don't see it in the data so it's not there it's like yeah you actually knew it was yeah I just said whatever you have to be afraid to do it it's there it's absolutely there if you cannot see it then you have to build that I do it so yeah I think that was one of the companies that were hit with a couple of 100 thousand euros of fraud later on because they simply were not able to detect it yeah so that's quite quite an issue so but I think quite smaller teams that are still making their company work trying to get their place within immobility yet they're not focused on fraud because it costs a lot of money to build fraud tools yeah yeah yeah if you're detected yeah to do what if you say wake up company x wake up what is the first message you want to say to some company that's just been waking up yeah monitor make sure that you start monitoring that's the whole thing make sure that you look at your processes and consult other companies because with any mobility we have like a workgroup fraud where we talk about these things okay because monitoring is a great bridge your first topic right the registration of your - Yeah, I mean, I agree with monitoring. The challenge though is when we scale and the companies here today have got major scale is just the diversity in the behavior of each token. We have users that go or do two sessions in July on their annual location and we've got tokens that do 30 sessions at a single point in time like carpooling where employees are just. So monitoring and identifying the difference between genuine and fraudulent use is a real challenge. But you need to start at step one and start breaking it down and understanding that not all keys are all tokens are the same. And that's so, but I agree the first step is to start monitoring and understanding your data. - And I think it starts then maybe with the registration. That's really where you start. - Yeah, if you break it down, a user comes to you and wants to charge somewhere and as an EMSB they typically come to you because they hear that you need to have an IRFD card so you can charge everywhere in Europe, super cool. And then the registration starts and not every company at this moment in time already has. It completely fix that they know exactly who that user is. And if that customer's going to pay, yes or no. Those are all kinds of questions that you need to get answered. But again, it's about usability. So you can do very firm checks like banks but probably won't have any users. - Okay, so the question leaves us the question, what's the best approach there? - Yeah, as a company you really have to look okay, what am I targeting for? So if you offer more towards lead or fleet or lease there and of course that's a different domain than when you target end users and taxi drivers or people going on holiday, that's a completely different set of people with. - Okay, so when I look at blue surfing that, I'll go to UMetView. Blue surfing is one of the first native EMPs. Just EMP, that's it. As a primary business, correct? - Sorry, so plug surfing has a direct B to see offering but that's a, but the majority again, of our sessions are clearly externally. - Yeah, I'm sorry, I'm not expressing myself very good here. - I mean, there are a lot of EMPs that are having the CPO role as well. And plug surfing is just one of the first companies in my experience that started the EMP product as something just stand alone. - Okay, meaning that we made a strategic decision to exit CPO. - Exactly. - Yeah, so we have pure EMSP offer. - Pure EMSP, I mean, yeah. - Absolutely. - As a pure EMSP, how do you, how do you handle the first registration when a new customer is coming? - So again, a lot of our customers, we need to look at this in plug surfing on a token level, like not user. We don't know the user in many cases. The users are managed externally. So, but I would say for the three step approach would basically be first. Like if we talk about you, you made a question some minutes ago about where would you start? The first thought is to define limits, rules that when infringed you act upon them. But then you soon discover that not all rules fit for everyone. So then you need to start making the rules more granular so that your customers can set up the rules as per their needs. But then that becomes an operational challenge. So then you start to need machine learning to act a little bit more automatically and adapt with the data. - And do you feel the same balance in between user experience and security as well as Peter just said? - Yes, I mean, we always talk about that internally that fraud is a constant battle between the user experience and fraud mitigation. I mean, quite simply say if you have no rules at all then your user experience for genuine users will be perfect. They will never be affected. But as soon as you start to have rules, then you will definitely affect genuine users at some point in time. So a good example of that would be we have a rule that one key won a car. So if you try and start a second charging session you will be denied. But unfortunately we have CPOs that don't inform us about stops. So if you haven't been informed of the stop, you think there's still a session ongoing, but there isn't. So you need to start thinking, okay, how do we still mitigate that risk but also ensure user experience? - Okay, that's one of the reasons why we were testing it and we stopped doing it. Actually, oh, we didn't roll it out. Where we said, okay, hey, we're going to not allow a second transaction happening because we saw a lot of home transactions, especially that were just not closed down properly. People just pulled out the plug and transaction was never closed. And then you drive to Paris and you're a Paris and you want to charge and then, no, you have already a session run. - No, the question is it's a token of really vehicle-related offers, related, I don't know. - So it looks perfectly not. I mean, it's often vehicle-related, but then as I said, we have car rental companies, carpooling and they wish to charge many cars at several at one point in time. So you definitely need to have flexibility, but in order to get around the problem that Peter identified there is that we now saw this and we decided before we had basically accept all the night in the authorization. Now we have warning, deny and disabled. So multiple warnings leads to, it shouldn't happen, it happens occasionally, but then if it happened, okay, but now it happened a few too many times, okay. Now we deny it, okay, but they're still trying. Okay, now we disable because the only way to remove the problem is to disable the token. - Yeah, so it's like traffic light. Like we are in short red and then at some point you hit red and then it just goes through red too many times you lose your license. - Exactly. But I think the difference here is that that that match always with looks serving, they operate more less based on the tokens and the registrations happens at the fleet companies. So they actually act as the gatekeeper there. I think it's for e-flux and for us, we actually have the registrations on our platform. And that makes it really difficult because, yeah. How can you define if, well, if somebody calls himself Donald Trump or Mickey Mouse, then okay, then it's quite easy and clear. That's probably not Donald Trump here trying to, but if they start using synthetic profiles, whether you use all kinds of names from one place, address from another, et cetera. - Identity theft. - Yeah, that's not a, yeah, theft is actually really stealing somebody's identity, but synthetic is really stealing elements of different profiles. And that's really difficult to detect because even if you go on a one by one basis and investigate them, you will probably find a LinkedIn profile with that specific name and a person. And you don't know if they live in that specific address, maybe for a fairly long time. - But don't you think the problem is equal to a garlic in companies or CBO in this particular? - Of course they have that as well, but I think for the, in this case, it's about who is liable for the cost. So for us, the registration happens in a large platform and if it goes wrong, then we probably have to pay for it. If it happens with the fleet company, your blocks are if it doesn't have to pay, it happens with the fleet company. - So then so do you recognize this phenomenon or how does if looks a road cope with this? - Yeah, so I think there was where our biggest fraud was the fact that we didn't know our user. So someone would come in, they'll give us information, could be a real name, but you know, we don't really care, but too much about the name and the surname, it's about the bank in details and understand if your contact number is a real contact number, email address is a real email address, and also do you actually have access to those? So initially we started off with no validation checks, of course it's again, customer experience versus trying to mitigate fraud. - Beginnish, beginnish era. - Yeah, exactly. Until you get hit, then you know, once you get hit by fraud, then you realize it can't let's be a bit reactive about it, which is never a good approach, but it's only way to start somewhere, how it works. - Exactly, that's what I understand from actually all the major companies who work in fraud, even Amazon, and all Louis Vuitton or whatever they say, we're not going to do this until we're hit with fraud. Also try to make that business case towards your management saying, "Oh, I need to spend a million euros on fraud tools." - Yeah, no, not losing a million. (laughing) It just doesn't work like this. - No, exactly. And that's the reason when it didn't happen, then of course we needed to look at ways and how do we validate the customer to make sure the customer experience is also kind of seamless. So we just did some normal checks, making sure that someone's contact number is theirs. So we actually send them an SMS and they have to fill in a code. And I think that's quite an important distinction between a verification and a validation as well. You know, it's good to give us a number, or contact number, or even an email address, but as long as you can show us that you have access to it, that's the most important. And to go with the credit limits, I do think it's a bit crazy that we were given out MSP cards with unlimited credit. It's like, "Give in someone a credit card and say, "Go wild." I don't know who you are, but go crazy. And at the end of the month, I'll try and get you money. - That's a good UC experience, then. - Yeah, very good experience. (laughing) And then we found that of course, you know, fake bank details, 'cause we also allowed manual pay at one stage. So they'll just put in any bank details there, except the risk for the higher costs that we will eventually choose. charge them, but they're never going to pay it, doesn't matter. So we also then started doing bank validation checks. So if you are now a customer that's using a standard, with an offer in the credit, you have to do a bank validation check first. And that means doing a bit of a debit to a penny drop from your account. Yeah, credit drop. So you can basically see, OK, you have access to that account, and that account is yours. We also then looked at, based on all the verifications that you do, we will then give you-- irrelevant credit limits. So it's going to be based on who you are, the more we know about you, the more we will need to give you more credit. All right, that's very sophisticated. I think Matthew wanted to-- No, I was going to wait a little bit more, man. No, it's just very interesting to-- sorry, very interesting to hear that you both have post payment solutions and are persevering with that. I just-- it's really, really interesting. I mean, the journey of plug surfing, we had both post payment and prepayment, but shut down post payment a long time ago. We tried to collect-- we collect email, first name, and last name. That's it. If you call yourself Donald Duck, no problem. Because we only work with prepayment. What we saw that was really interesting was we were quite worried about this for our direct B2C offering that we were worried about losing volumes when we were communicating to users that we no longer offer post payment, I'm sorry. But what we saw is that users didn't stop charging with us. They simply converted to prepayment. And the difference in death levels is, I think, in the last six months, we have under 0.1% in non-payment on obviously our-- That's really low. Yeah. So we just couldn't justify it. Of course, another reason for pulling it away, apart from that users didn't seem to mind, is that we could put that time and energy on manage roaming instead. Do you think the fear of other EMPs on this point is quite irrational? No, I can't say I'm one or two answer that really. But I think it's a fantastic customer offering if you can make it work. But we were at the crossroads where we were like, shall we put time and energy in making this work? And that's why it's very interesting to hear that others have made it work. But we made a-- we took-- if you want to say the easy option to shut it down. It's the S within EMSP, yeah. So the service. It's the service, yeah. So if you define for us as a white label platform, also if it looks like, OK, we want to deliver the service of a post payment solution or direct debit or all kinds of other different, that's the service that you want to deliver. But yeah, then you obviously need to double down. Yeah, so the service takes some risks. It's not that risk indeed. And that's-- yeah, in the end, typically that base, but yeah, we have a team of three people on fraud here, alone plus three developers on it. And that's, I think, the biggest team that on fraud would enable it this way. Yeah, because we really have to focus and check everything that's happening. Did you explore the-- you obviously have a build-on buyer approach as well, and you've built your solutions? We've built some tools, and we're most likely going to buy some more tools because indeed, some tools are something. Something that you cannot build yourself. Like for example, we're looking also, since we're all need to go into kind of financial institutions quite soon, I think you need to have an ID check. And well, you're not able to build that yourself. So you need to just buy that. There are also a lot of tools that check IP addresses and that kind of stuff. Yeah, that's something that we all obviously never going to build ourselves. So that's something that we're also investigating and buying. But we build-- and that's quite unique in our industry. And that's something that we also need to see. And that's what I saw with all the other discussions on fraud. We have unique data that is not anywhere else. So we have to see the art data. We know exactly which doggone is charged where for how long, how many kilowatts, et cetera, et cetera. And we can combine all that data. And that's something that all the other fraud industries don't have. If you go to Amazon, you have a account with a name and address, and an email address and phone number, that kind of stuff, and a product that is sent to an address. And that's it, an abayment that works or not. So for them, it's really a lot more difficult. So the tools on all the transaction, I think you-- I look at you, Matthew, on-- I have a professor. You also build your own tools based on the transactions. Because it's not something I think you can buy, to be honest. You can buy machine learning on top of that. But it's the actual intelligence on how does an immobility transaction work. And it's just not out there. I've looked everywhere. I talked to many companies. And they said, oh, that's quite unique. We don't have that kind of stuff. I mean, I guess our two main focus areas are making pre-payment really work. I mean, obviously, the classic frustration is, as we all know, immobility. Sometimes you try and charge a car, and it doesn't work first time. And it happens to me this summer with multiple reservations on my card. So we've really focused on making user experience very good there, with not releasing the reservation upon a failed start, because we know the user's going to try again. So even if you move to a new connector, we still hold that reservation. And then, obviously, so I mean, we were very afraid of having multiple reservations held for multiple days. So we've done our best to-- But it's quite unique to build that you build. It's very immobility-specific. It's not just a simple reservation. You need to hold it for a certain number of minutes. I think our PSP defaults to seven days, but we never would hold it. Use this money for seven days. We take that an element of risk to release the money if we haven't received the-- We did the same as well. I think we received a little complaints about that. If someone does have a failed sequence of transactions, is that 150 euros just such in their way to be released? It's very frustrating. That's a main issue, by the way. That's a lot of strip. And then you get a lot of reservations in your card. That's a main issue in the UK for-- there's more than 50% full of transactions paid by credit card. And there, you see a lot of people that have to wait then for seven days to finally get older. At each time 50 pounds that they wait whole from the second. And if you just are like a taxi driver, whatever, and you're not fraudulent, then still, at the end of the week, you're roughly half like 500 euros blocked on your account. Which, for them, it's a nightmare. So it's the weird thing is there where we see in Europe, a lot of people want to switch to credit cards. Whereas in the UK, a lot of those users want to go to an alpha-d card because they say, OK, no. With a post-baby solution, OK, fine. Let's do it like this. And sometimes they have a prepaid solution or a post-baby, which is per day, for instance. Yeah. All right. This is a nice bridge as well. Because the UK and your main Europe has to communicate a bit more with each other. And our next topic was communication and data between EMP. So how does that actually can help preventing fraud? Well, the problem that we see right now is because it's a young industry, is that data that flows from a CPU to an EMP is sometimes not really 100% correct. And a lot of those times it's not maliciously. It's just because the systems are not really running fine or the protocol is not helping or all kinds of reasons why that's happening. But yeah, it causes a massive amount of problems that for an end user can look fraudulent because a duplicate transaction or a transaction with that has not been closed properly, for instance, which has a time to wait on it, which suddenly can have a transaction of 1200 euros and typically that's a mistake. But that's the problem that you see. And that communication, in this case, it's purely technical. I think it's a massive issue. And there's a lot of companies like us, and I think also Matthew, you mentioned it before to me, it's like, where you have to do an amazing effort to check every single transaction over and over again, more or less to see, is it correct? Does it fall within all our rules? Is it set to a correct invoice? And if the invoice is set correctly, can we then pay it back to the CBO? So there's a whole pile of checks that we need to do before we actually say, OK, this transaction is really cool and good. Did we make it complex as an industry? Yes, but-- The two complex-- Well, on one hand, maybe yes, but on the other, we have kind of a unique ecosystem in the world. And we have, as I mentioned before, so much more data than anybody else that we actually can stop fraud almost in-- even if you don't know the end user, the second transaction sometimes, where you say, OK, hey, this is weird behavior. This is location that is-- we know is wrong. You're charging too much for the second transaction. Well, I think in this space that we're talking about now, I think the single biggest issue for plug surfing is basically paying for the same service more than once. Yeah. And here, there are multiple phases during the month. So you're sent a CDR. That's the first point that you need to make sure you haven't already received this. So we have duplicate checks there. So I think in the last month alone, the number of duplicate CDRs is 10 times the level of-- and use another. So it's a much bigger problem for us. But that's what I meant with us managing the network on behalf of RMSPs. They don't see these, they don't see duplicate transactions on their invoices because we capture those. The problem then is, like, we were, then we reject that CDR. We would say, no, we're not taking the CDR. You've already sent it, this key on this connector at this point in time can't charge twice. It's not possible, therefore we reject it. The problem is at the end of the month you get invoiced for it. And then you need to say again, no, but we said no. And that's a much bigger problem. So you have to have several checks in place to protect the user and then to protect your own invoicing process. Do you feel like you are constantly educating CPO's on this topic? I would say so, but I would also say it in a positive way that it's getting much better. And then when we have consolidation in the market where we have, hopefully, a fewer larger CPO's, then it will get even easier, of course. Do you feel that's more like, I know in the German market, for example, they generally would send more than one CPR, a CDR based on the fact that they do not send the cost of the CDR. And then they update it eventually after. So you see a lot of duplications based on that. So I would answer a little bit. We've seen it all. But so to avoid details, we've seen the exact copies of CDRs with new IDs. We've seen, I think, the situation we're describing, we get a CDR with no energy and no cost. And then we get sent minutes later, the real data. So now we have to be, this is a new situation. Now we have to start not rejecting the duplicate because the first isn't real. And it gets colourful at times. And I guess this is the whole thing about the customer experience compared to the actual fraud. You know, you get a determine which is fraudulent and which is actually just a pure mistake or lack of process. Yeah, I mean, from a duplicate perspective, we would cut it off at the beginning there. So we would take the risk. We take the brunt of it. And then we need to make sure that we capture that in the invoicing process so that we don't pay for something. But then, of course, we see it doesn't end there. We have the same invoices being sent twice. Different invoice numbers. Exactly the same amount of the euro sent. Sometimes even different senders. We have CDRs that are only sent once in the CDR flow, but sent multiple times in the invoicing flow. I mean, you really need to have your processes and tools in place. Yeah, it's actually quite demanding at this moment the whole roaming process. Because, yeah, I think we're being more than 500 invoices per month. And we over have to check that. And that's that's probably roughly five million transactions per month in a company. Which half is roughly as an MSB. So that's a lot of transaction that you have to double check. And then double check if it's correctly invoiced to you. So if you're looking at it from an administrative perspective, is it more like an administrative problem? So if every invoice is just, if there are CDRs accordingly to every invoice or. Yes, but I think the major issue that we have is that we have so many partners that we're connected with. Like if you look in Telco, I mean you're connected with 10 maximum big players. More partners, more problems. Yeah, but that's really what it is. And half of all these partners are really uneducated, have no clue what they're doing. Yeah. Too small to care. If you're a start-back in Germany sending out your own invoices, most likely in your whole municipality, you have two people do a mobility and they have to do everything. To make sure you. If one people just listen to this podcast, there's one person of that two people. Yeah, that would be super cool. But they can still not solve that problem because yeah, unfortunately this is how it kind of organise. And that makes it difficult. But I think the biggest problem is you mentioned with Telcos. Right, Telcos is a governed industry. There's licenses that you have to get to operate as a Telco. But here you don't. You can kind of just become an MST or CPO overnight. And the data exchange, there's not strict enough regulations as to how you should follow the data. So this becomes an issue as well. So when someone does send us information, we expect an Internet in a certain format, like you mentioned. But it's completely different than they do not conform to the spec. Because it's also, I think some people think it's up for interpretation. But it should not be. That's also a bilateral contract. So that's what we also have. Like bilateral roaming contracts specifies, okay, no, we work via the E-Violin Defined Format of CDR. You have to try with Microsoft Excel guys, come on in. That's still useful. That's actually one of my jokes for next year that one of our objectives of 26 should be to kill Excel. And it's like, yeah, I mean, it's come, it's a data all over the place completely disconnected. Yeah, maybe you need Excel to survive now, but that's not a solution. That's going to scale. What typically was a joke I didn't talk. It was actually, no, it is actually the case because what typically happens is that you get your CDR like more or less real time within 15 minutes. We agree that you have the data at the other place. But then at the end of the month, all the companies send a file like, okay, you have an invoice. That's, I don't know, 500,000 euros plus an Excel file, CsV file that contains all the transaction that are in debt. The thing is, I also have my background in Telco. So I think, and they're in Telco, you have interconnect systems, clearing houses. All the data just comes in and it just says, you owe you exactly this much. And now, do you not think that we will be there? If we sat in the room five, 10 years time, that we wouldn't, that everything that we're, these are just teething issues. I think a lot of it. I think so. Yeah, I think it's definitely moving. It's so similar to industries. It's a national progression to get there. This is actually a great bet from Matthew, right? I don't forget the work problems. Butters of wine. Before 2030, this problem has solved data problem, that's changing problem. It has to be, and it has to be of, yeah, of minus significance. I think it will be solved. But the work companies in the past try to be a clearing house, actually, E-clearing or a sligharker was called, but they also failed. That's more or less. They were not able to somehow deliver the service that both parties needed. And, and, butter companies that are coming that way. And, and to be honest, if you look at those three companies that sit here on the table, that were big enough that we in the end are going to say to each other, "I owe you this, I owe you that, based on. " Because it's a serious deal. It's with e-flux, because we have kind of a similar in and out. We're more or less balanced out. Yeah, but we're not paying X amount them to us and vice versa. We just balance it out like a cave. We owe you. Yeah. There's the rest. That's more or less. But that's a start. But still the data, we also need to go there and simply say, "We rely only on the data that we've sent before, because that's correct." Yeah. And not on a CSV file. The CSV file should just be basically a reconciliation of what's in the invoice, right? Exactly. Yeah, absolutely. Do you think there's a color collaboration? Collaboration. Collaboration? No, just a connection between bad enforcing and bad CDR sending and higher fraud issues. Yeah. More fraud issues. I'm beginning to suspect that some CPUs are sending more CDRs than they should. And some MSB operate in our domain that are actually not an MSB. And still they collect data or kinds of other stuff. Okay, so fraud could be taken to another level. And we've not seen it that outspoken that it's happening. But I have -- well, I see some stuff that I'm very dubious about. I think, "Yeah, what's happening here?" But it's really difficult for us as a company to define, "Hey, has that session really happened?" Did somebody really charge 20 kilowatts? If the end user doesn't complain and say to us, "Okay, I've never been in this location." Yes. So that's really difficult to define. And yeah, I've had some, let's say dubious CDRs that we've seen, but we saw no complaints. So for us, it's like, "Okay, we cannot really do anything about it." Maybe you can apply to investigate every year. No, exactly. But -- It's an injection, of course. No, that's the difficulty. And the other end is like, "Yeah, we're receiving MSBs that actually got connected to us via HUP. We have a different system, so we are not immediately connected to us. So we have to first set it up before it actually works." And they never contacted us. And we tried to contact them on an email address, and they never did. So it's kind of weird. So you want a room on a network, but you never contact us. You never bring us the actual details, "Hey, where should I set my invoice to?" You cannot set a phone call to me. It's kind of weird. You were just trying to, yeah. But at the same time, they actually get shitload of data from us, from all our locations. Well, they give tokens. Well, we don't know if they're really us or no. So they got a real sense of data. And the same with CPUs. If you start a CPU with just two stations, open it up for your roaming, everybody will connect. And suddenly you have the data of all the UIDs, the tokens out there in whole of Europe. Yeah. It's a risk itself. It's a risk itself. Do you think they are a ghost in peace? I think they were absolutely. I think I have white suspicions in the past about at least two to three companies. Why would that be a fluctuating in the evenings then? We've had as well. Definitely. Making a joke here. That's the first time we can call them. So that only needs a piece. But I think you just touched on the elephant in the room with RFID cloning. We had several subjects today like Identity theft. But really the single biggest risk to us is RFID cloning. For the pure fact that as EMSPs we send out all of our RFIDs to a range of CPS. And then the chain is as strong as the weakest link. So you have to assume that your data will can leak out. And this is why identifying cloned RFIDs is of utmost importance. Meaning parallel sessions, distance and time between sessions. But again, we have CPS that have incorrect coordinates and incorrect data. So you have to, that's why I say again, warn, deny and then disable. So my take on this would be as long as you build enough friction in the process for for for instance, then they will they will find platforms that are less. Yeah, less protected. Because the thing is they want they want to industrialize this right as soon as they find a weakness they expose it. And then weeks later they they have a fully scaled solution which they offer to the market on for example telegram etc. So you think the upper. Okay, just talk along I lost my question. No problem. No, but I mean, so build the build friction. I mean, this is why I think it's fine being it a you know, we are the you learn from your mistakes and collectively. You know, if we share our share our learnings with each other, then that way will be better equipped to deal with this. That's exactly what what I've heard many anti fraud or cybersecurity. Yeah, so much where I've been is actually you cannot do this alone. You have to do it together. Yeah, that's what my question about I remember it instantly. You send an amount of tokens to your trusted partners, right? It doesn't this has something to do with what you contractually talk to each other and just reading your yeah. Yeah, your name under the document. Yeah, but but there's I mean this is now getting into the main item. Actually, when you send your tokens out, you can say whether you need to be asked if they're allowed to be used offline or not. And then the plug surfing off. I believe that we're considering going into allow offline, never meaning the CPU must ask us for each and every exactly because then we can build a whole range of. You know, now we we have an element of risk by allowing them to be used offline. So yeah, the wireless problem. Yeah, so we actually did that. Yeah, we did. And it was in the game. Custom experience versus fraud and we had a lot of complaints from customers about the fact that they were not able to charge. And again, it comes back to the CPU and not been conforming to the fact that you need to go back home. Well, we call it home, right, which is the MSP to see whether this this token can charge or not. And then we had to eventually switch it off. Because of the fact that it's still big problem. Yeah, exactly. So then eventually we changed it to little bits just to make it true that we still have that validation. But we now we defaulted back to allow offline. It's exactly why we didn't start it. Yeah, that's very interesting. But it's very annoying that CPU is coming up. No amount of like 30% of sessions would not start or. Yeah, I would say about 40% actually. It's a pure. Yeah, because the other side of it is the location, you know, the CPU could say, hey, this token would like to charge and they would like to charge here. Because we have many customers that have, you know, fleets only in Holland. Why would they charge in France or Belgium? So we need the location to be able to see. Yeah, so we. But many CPUs don't provide that in the online office yet. Or yet. So, yeah, it's good that we talk about this because that's exactly what we want to discuss within the work who fraud where we more or less look at all the different enablers, will tomorrow's organization is one of them where we say, yeah, the fact that it's missing will tomorrow's organization is an enabler for fraud. But we need to come together to a solution where we say, okay, for instance, indeed the location we need to have that ID when you do an auto does that's that's a must and secondly, we're maybe are going to say, okay, as a. As a condition, if I have a contract and you're part of the work who fraud, we're all going to do real tomorrowization from a certain date because then we bring it up for the listener, the work group fraud is part of E violin. Yes, everybody can join them. Well, if you're a member of E violin, you can join indeed. So you should be a member. Yeah, you should be definitely a member there, but but if you're not just just contact me for instance, no, but we saw quite a lot of companies that actually became a member because they wanted to participate in work of fraud. And if you lost that, I don't know, a couple of hundred thousand euros and you have no clue how to deal with it, then it's good if you have a place where you can at least listen into a lot of players that actually are constantly working with it. Okay, so to all the listeners, just joined. Yeah, this was a public announcement. That was a service. Do you think that this, again, now, when you know with smaller CPS MSPs, the amount of calls that you need to do, you know, to do real time authorization increases quite a lot. So some systems are not capable of doing this. This also becomes a bit of a problem because that's where you find that they might want to do it, but they just don't have the capacity to do so. And that's in the end, I think a career choice for that company, because if you cannot deal with the big boys, then you just leave the field. And this is where the whole quality versus quantity discussion comes in. You know, before you know, like, so we have 400,000 connectors, 500, you know, but now we have over a million connectors. So do we need these small CPS? You know, that's a certain point, no, but there are still locations like in Germany where, yeah, if you want to charge in a municipality, you have to be good. Exactly. That's the most serious one. And also in islands that for its creation, they just have a closed lock-in network that you have to connect to. And that's the only place where you have to be. But the whole discussion, again, between user experience and technology. Exactly. But the end of the day comes down to a business case, you know, you can't have higher operational costs for a friend at CPS than you're generating from some. Exactly. And the problem also that then we've encountered with real-time authorization is really yet the delay that you get in, and while you can swipe your guard. But if you then typically you leap within a second or two seconds max, and it starts working. And if you then have to wait for, don't forget how complicated it is sometimes you have a charge station and Italy that first has to go to Austria, then via Austria to Germany to the Netherlands to find out can I charge yes, and then the whole route back. Yeah, in principle that should take milliseconds, of course, but it doesn't take typically takes four to five seconds. And for an end user, that's already too long. So the end user then starts swiping again, closing the session. The good vibes again, opening it again, it only makes it worse. But the end user doesn't know because there's also no feedback on that device saying, hey, I now need to check something. Yeah, no screen to give you an indication. I think you could probably say that a good IT environment is really helping for detection and prevention. I would like to refer back actually to the allow offline. When you, did you experiment with that or was it a clean sweep that you changed all your tokens to allow it offline never? It was a clean sweep at the time. Yeah, because this is another like tip of what we do at plug surfing. We often pilot new new initiatives so we segment users. For example, we're looking at the our level of nonpayment is so low. For example, at the moment due to so we're actually experimenting with not doing a pre-auth on the card for trusted users. So you want to experiment with this and see how you go. That was really good. So all new ideas when you're working, we talked about what would be your first step. Basically, try to prepare technology that you can experiment with new ideas to see. It's really, really important for us. There was a nice learning because that's exactly what we had to do the second time round. So we reverted the change and then we did it again, but did it with trusted networks. We know, you know, conform to the protocols. We also have the issue with, well, you mentioned them earlier, the hub that you mentioned. I don't want to call them out just like that. But they were not an OCPI. So, you know, you would never get real-time authorizations there. It was interesting because we had real-time authorizations. authorizations on most of the actually on all eventually again, but they found loopholes by going through E-Clearion stations And then they would never get you know blocked because the real-time authorization was not working on those ones Okay, so first is a pretty interesting fact that they know exactly what we saw as well They know exactly to show the we saw a couple of Fraud cases that hopped from company to company Both also had to do Romania case. No, yes, I know that So we're 14 to 15 companies. I know that actually had that case and they all had to do something about Romania cases public Well aware, but yeah So the first and who actually found out that case really knows our industry that cannot be different than that because they Actually knew exactly how to hook from one to the other knew exactly where to do it. Yeah, and how to do it and Yeah, so and that indeed we had to educate people at that point I was okay. No, hey guys. You need to know But I also heard about the company that more or less that came complaining to me in the work group Yes, since last week we certainly have some mass amount of fraud within this country and then we say yeah, we blocked that last week so They jumped from us to you Good luck And that's exactly what you said met you. It's like yeah, yeah, we can close the company and you both can also close that for for certain frauds But they will find a way that we're going to the weakest link Yeah, but that's why this discussion is so valuable because you can you can talk to each other and say okay We managed this this way. Maybe you can try this or that pro sure Some bad I use a group or whatever you prefer to you know to just Prevent other companies from making the same mistake over and over again. Yeah, exactly and and and and the end And that's what I also learned in the summit is really if you close as a industry everything kind of down The fraudsters move away because they have no product to sell and no money to be made and then you're just left with With the petty fraudsters and and and yeah, and even that you can close down quite quite quickly Because the professional ones. Yeah, they they have no interest They will just then use all their knowledge or or development power somewhere else they make business cases to Yeah, of course they make a business case it doesn't make any sense And that's what we see now our fraud percentage at this moment is - 0.03 Of all our transaction at this moment Which is quite low That's not not payments. That's different for us. I was gonna say that's Really impressive. Yeah, no, no, no, we really look at it as two different approaches So non-payment became and we know this user and he hasn't paid to that something different then Okay, this is definitely a fraudulent behavior by somebody that we don't know something about the 0.03 percent are actually sessions you identify Yeah, we identified we will we identify them as fraud We block the users we block the cards that kind of stuff And that's actually lower than credit card fraud at this moment in time. So we're actually doing quite well So that this is again making a nice bridge Really impressive to irregular behavior of the The tokens you are investigating. Yeah, but that blocking itself still is manual Yeah, we do this manually at this moment in time because we don't want to go into a situation where computers says no Universe a program no, we don't want to have a A situation where we cannot explain to the user what has happened Because the computer machine learning I said no, you're fraudulent and that's sometimes what you see right now within credit card Companies and banks they sometimes block your card and you just get an SMS or whatever saying hey We blocked your car because we saw for And it's like okay, but hello and I call somebody and that's typically not possible So it's really quite a pain in the ass and we don't want that But you need automation on certain levels. Yeah That's the challenge right between does the user want that or not? Because if they if it is fraud then they want you to block it Of course, I mean this is I mean even though I mentioned that we do most of our clearing externally We still have what we call events that our MSPs can subscribe to for driving user communication So for example if we deny an authorization as an event for that so they can Or if we do automatically disable a key then there's an event for that so you can yeah Tie in a simple no, this is me flow to that and reenable your key, you know So so there I think there are it's not deny the raw it's about you know Building use cases that that's you know can automatically disable or deny but also allowing users to communicate No, but this is not fraud. Yeah, okay, but it's for us I have to have mentioned here that we typically block the car But we are not communicator with the end user because our customers need to communicate with the end user So it's really so we send that heavy to our customer and then say okay, you need to contact the end user to say that we blocked their car because of foreign behavior or indeed or And send them a new card if you think it's actually if it's a proper user. Yes, I know But we also sometimes say yeah, we blocked this account because we see this address multiple times we've seen this email address multiple times And typically our customers can only look at all their transactions Their own transactions. Yeah, we can look over the 150 customers all the five million transactions see all the patterns there and Yeah, that's that's where we I think Benefit from so much data. Yeah, we're even going further. So looking into software We can even go detect even Devices or other stuff where we can actually simply say okay this device has been used by fraud there shoot other companies We be using this benefit of looking at large amounts of I think book serving and if looks are good example, so you share some some Views on that on how a company's like last-mouse solutions could share a bit more Information about I don't know bad players or what we're doing is is looking at the at at data that we see as fraudulent and we then Contact the roaming partners. That's the only thing that we can do we cannot suddenly say hey this user with this email address is committing fraud at our Have we looked at this also to work who brought look at can we make a blacklist blacklist? But the problem is that you can only do this in the Netherlands for instance You cannot make a European blacklist. Can you with GDPR as well? Well, you can in the Netherlands I looked it up there's some ways that you can actually do it, but that's just the Netherlands yet But typically I also had a contact with the police if you then say okay, hey, I've got a fraudster from Germany. We know that Frauding in France with a Belgian account on a Dutch platform Where do I go to and they don't know and that's the same here. It's like yeah, okay. I can have a blacklist in the Netherlands It's a lot of work. I have to be said a lot of things before you can actually do it But you find a unique identifier that actually brings it to that customer exactly identify that this is exactly like Yeah, like how you would have in financial institutions You also have a blacklist or pepless or but you could only have a blacklist if you have an ID check at the front So that you actually know okay, it was Peter who was falling do you think that's been necessary in the Emobence there. Yeah, that's India and I think if you're dealing with payments at a certain point You will become more and more like the banking system. You should be a beautiful KYC track really if you handle in money and taking money from one person and giving it to another Again as I mentioned earlier the whole money I don't think it's about here. Okay. Why see at the moment? So yeah, yeah, but I think that's that's I think we mentioned the same in the say at a podcast last time I mean BSD 3 is coming our way I think next year and all our companies if you're big and you deal with a lot of money and take money and Push money the other side out You have to adhere to the PSE 3 and that means that you have to adhere to KYC. Yeah But you're talking about individual uses that you see are acting fraudulent. Yeah, yeah, it's essential because From my side we will be looking for patterns where hundreds of uses are are behaving fraudulent using the same you know Oh, we do that as well, but we actually bring it back to to I mean we have some cases in in front in this case where we see hundreds of occurrence created exactly Yeah, but that's just one person we exactly out. It's one person might be the same person up that from a could be and and And that's the thing is and we're now looking at it for instance Okay, can we define the patterns that that person has since their users too because typically sells this product to in this case Taxi drivers around Paris or maybe you know this case, but yeah, we were already looking can we maybe send out to other Emispiece hey look out any transaction happening on these and these and these charges for us are like 80% of the time fraud Because I think that's that's the key isn't it to find find the pattern and kill the pattern Yeah, so I mean we've had history of You know when we talk about fake user accounts with disposable email domains, you know So we integrated with a service that we just don't allow users to sign up with those domains we did the same. Yeah, it's so that helped a lot then we had You know when we had some back in the day with some ways of getting around prepayment We saw that this was all related to particular bank identification numbers and okay We went into our PSP don't allow cards from this PSP until you've solved the underlying problem Yeah, and now one of the things that we talked about earlier before the podcast started was a identity theft. Again, like, you know, so emails and passwords being obtained on the dark web. And then you don't see one user acting for it, and you see all of us on hundreds of users. - Exactly. - And here we saw this through our warnings on parallel sessions. And then, and now we no longer allow users to sign in with passwords anymore, because, so we send what we call a magic link. - Oh yeah. - So basically you can only, you can only access user account if your email account is exposed. - But then, again, that's all the balance of, okay, what are you going to do, which is user experience and the fraudulent. - The session, at the same time, I think is really good. If you get a lot of requests from, in once for 100 new art tokens, and you can identify it, it's a pretty good start. - We're going back to this whole tug of war thing again between user experience and the fraud mitigation. So you can have fewer rules, but when you're under attack, you have, you lower your tolerance for pain, basically. Until you've understood the underlying situation, address it, and then back to, yeah, more relaxed rules again. So it's really important that you can identify patents and act as quickly as possible. It's un-un-un-un-a-personal, though. You've all been working at the fraud topic, right? In your professional perspective. Is it possible to trust anyone after one year of working on this topic? Or do you get some trust issues for you? - It's a really interesting question. And I think with these businesses that are high volumes, you have to look at the glasses 99.9% full. (laughs) Otherwise it kills you, right? So it's the same with all the topics, like price accuracy and everything. You have to look at how the numbers for a percentage perspective are getting better and better, and not looking at the absolute problem that the actual percentage is. - About that topic, too. (laughs) So most of it is works. - Yeah. - Yeah, so it still is, it was the same conclusion at the last podcast, and I'm moving a bit towards the end because we had a one hour mark, but one of the conclusions was, okay, the problem isn't big enough, maybe, to push all red buttons and alarm, like, that's what I said. If you just lost 100,000 euros for a small company, that's a lot. - All right. - Might mean bankruptcy, but yeah, for any of our companies, we lose 100,000 euros, we shake it off, and then we probably continue. We still get angry managers, let's face it, we say, it's like what the F blind, it will do so much money. But, but, but, yeah, that's what's happening. But again, as I said before, I can buy for a million euros, all the tools that I want, but I don't have a million euros of fraud at the moment. So it's really a difficult balance, and make a business case out of it. But then again, there's regulations that's coming in, so suddenly you have to do certain things at a KYC, that's something that your most company simply have to do, and maybe block surfing is your customers that have to do this, and not you. But yeah, for us, if looks, and last month's solution, we really have to start doing this. And you have to fill in other checks as well. And if you don't, you get massive fines from the Dutch bank, for instance, where they find the rabble bank, 700 million a couple of months ago, for just not doing a KYC check properly. Yeah, that's, we are, let's face it, that would be a bankruptcy for now, yeah. - Definitely. - Just one more topic, just one elephant in the room, we didn't discuss, but it's still high on the list. It's RFID cloning, right? We discussed the bits, but what's, you have two tokens, one person. - Yeah, what's the greatest risk of that? - No, you have two things that you have to look at. One is the copying and cloning of data, just real data, and with that data, you can do other stuff, of course. And do remote start sessions, for instance, but also create tokens with that stolen data. But the majority of what we see is really end users, either maliciously or not maliciously, where the card has been copied. And I mean, if you go and look up a TEMU and AliExpress, and then you can find the tools quite easily to do this. And if you're a bit tech savvy, you know exactly how to do it. And then you can make some kind of a product out of it by reselling it. I mean, if you are just doing it and copying it, giving it to your husband or wife, and then you use it on the same account, and you still pay the bill. - Yeah, exactly. - So, really your problem, except that some of us already said, no, one token can only charge you once. And that's, again, that's kind of a user perspective that you're going into. But yeah, the cloning itself is a thing, yeah, it will happen. We've chosen a technology that was hacked already when we started using it. That's something that can happen. But it's about the monitoring. So, I think we all three detect quite early on when a cart has a simultaneous transaction. - And the same thing is a transaction. - The question that the oyster cart in the UK is just a great example of it. They use the same technology for public transport and there's no problem at all. And the amounts are too low to actually make it happen. - Yeah, but the amounts for us are getting too high, because if you're trucking, it's now getting into, and those are transactions 300 kilowatt. That's immediately here towards the 150 euros or more. - Yeah, I see. But you could state that RFID cloning is only a problem when you have your other processes not in other areas. - Yeah, exactly. I always see it. It's the same as credit cards 30 years ago. Those were days you could clone them, whatever. But it was the banks who solved it at the end where they more or less said, okay, hey, you know, it's being cloned, something weird is happening. We block it. - So, if he's a generated.exe. - Something like that, but it's kind of what we're doing as well. So we see if a card is cloned, and we see simultaneous transactions, but also other patterns, that's not just that. Also other patterns. Then we immediately block the card and ask our customer to send a new card. - Yeah. - Let's face it, then we know. And if that happens again with the same user, then we obviously don't trust the user. It's really like, hey, what's going on there? - Yeah, so eventually this problem will become less and less more effectively fraud methods for fraudsters. - Hopefully, I don't think that'll be the result of bullets to be honest. - I think it will. - I think it will be easier for other processes. - If we go back to E-Vion, we also have a work group security on token security, where it has also looking at all kinds of different ways that we can use token. So there are now two methods that we can use that are a lot more secure, either going towards the EMV. So that's the Visa Mastercard and solution. Or we go towards a different solution that is more protected than suddenly it makes more sense. But again, if you want to do that and move over, we have more than a million stations out in Europe that do not support that. - That's exactly the same. - In the discussion again. - And my reflection here is that it's done on me that it's really important that we talk with each other and what we expect from each other. What does the driver expect from their MSP? What does the MSP expect from plug surfing? Like what does plug surfing expect from the CPO? We haven't really had those kind of discussions. So at the moment, plug surfing is kind of, we do what the best that we can do with the situation. But I think we need to start breaking the problem down and being clearer about what we expect from one another. So that we offer rules that the driver can configure. We offer rules that the MSP can configure, depending on the, you know, their needs for charging the scope, basically. And do what they cannot expect. - Yeah, to me. - But it's a little bit unclear about who is responsible for what right now. - Yeah, yeah, yeah. - Yeah, that's something I think within Evalin, we try to configure a bit. However, there's obviously difficulty that, we're competitors, but we cannot talk about terms and conditions, we cannot talk about pricing, we cannot talk about indeed aligning everything that we do. - All right, have I forgotten something in any topics we have to address again or what? - No, I think from a MSP perspective, I think we've covered quite a lot already. A lot of things. - All right, thanks. - Any questions there? - Oh, it's really interesting. Thanks again. - Okay, great, thank you. - Thank you for being here. - Thanks for having us. - And posting this show and then we call it a day. Okay, so to all the listeners, if you have any questions, you can of course email a laptop thing at [email protected] and of course in the show notes you'll find the necessary contact details to contact us or any of the speakers today. Thank you for listening and have a nice day. (upbeat music) [Music]