So for those who just joined the session, my name is Ulrich Herberg, I'm a Senior Director of Engineering at eBay and one of my focus areas is identity. And today I'll talk a little bit about eBay's experience on Strong Customer Authentication, which is a regulatory framework in Europe in the PSD2 regulation. And I gave a similar talk last year, but I wanted to have a different perspective this year, more related to other European regulations as well as why it was so difficult for us to implement this. As I mentioned in the panel, there were over 100 teams involved in eBay to make this happen.
So I don't want to – I assume most of you know what eBay is, it's a big marketplace. The one number that I think stands out is the 134 million buyers that we have, and plus we have also several million sellers. So there's a ton of users that we need to – that have to go through Strong Customer Authentication. Not all of them, of course, are in Europe, but still we have – the identity system is huge and we all implemented it ourselves. We don't rely on vendors typically.
What fewer people know – everyone knows eBay is a marketplace, but what fewer people know, eBay is also a financial services company, more and more so. We're having those regulations, payments, institution service, e-money license, those kind of licenses. And the reason is because we want to offer more and more financial services to our users. So one of my teams, for example, just developed and released what's called seller capital or seller financing. So in Germany and the UK, you can now as a seller get a loan on eBay, not from eBay, but via eBay on the eBay platform.
And you can also pay back the loan via eBay. You sell and a certain percentage of your sales price is withheld. Another example is we have eBay co-branded credit cards in certain countries, and we can also keep the proceeds of a sale inside your account. You don't have to pay it out immediately, and so you can use those funds to buy on eBay, to buy shipping labels on eBay, or to initiate a refund or return. And so because of that, we fall under this PSD2 regulation, although we're not a bank, and that's kind of what's atypical. The PSD2 was mainly aimed at banks.
The regulation itself is – as you can see here, you can see the links. It's published in a regulatory technical standard. It's a separate document from others in PSD2. There are two versions of it, thanks to Brexit, which is one of the complications I'll talk a little bit about. There's a UK version and a European version.
Most part, they're similar, but there are some differences, and that's actually something that we were surprised initially about. Now, one thing I want to clarify. You may know strong customer authentication. Lots of merchants offer them when you buy with your credit card, but in this case, the SCA is performed by the issuing bank, by your American Express, by your visa networks, or by your actual bank. In this case, because we allow the sellers to keep the proceeds in the account, we are the bank, or the term in the law is account servicing payment service provider.
I have to read this up every time because it's just hard to pronounce. What the regulation requires is that you perform SCA every time a user accesses payment-sensitive data. This could be your transactions, your balance, your account numbers, as well as when you initiate a payment transaction.
Luckily, the regulation offers certain exemptions because they realize it's friction. They want to protect the user, but they also realize it's friction, so we can use exemptions when it's a low amount or a low-risk transaction, or when it's a regular recurring transaction, let's say, to a company that you trust. SCA is two-factor authentication is another word for it, so two out of three buckets, knowledge, possession, and inheritance. Some samples here.
Knowledge, everyone knows the password. Possession is what you own. Passkey is where you own the private key, or SMS is where you own the phone or the phone number associated with it. Inheritance would be biometrics, such as fingerprint or face. eBay offers a ton of different factors, so passkey is certainly the one that, as I mentioned in the panel, we'd like to see the most of an adoption, because we think it's highly secure and low friction.
We also have push notifications sent to those users who have the eBay app on their phone, but that already limits it a bit because not everyone installs it on their phone. SMS OTP is the most common one. It's the one that's the least favorite for me. It's not only less secure, can be spoofed, but also it costs a ton of money. My lawyers told me not to tell you how much money we pay every year, but if I had that money for myself, I wouldn't be standing here, but I would be in Hawaii on a beach. Email OTP is even less favored than SMS OTP. We only allow this in limited use cases.
Authenticator apps, you may have seen those, the Google Authenticator app, Microsoft Authenticator app. Large companies are going away from it. We still support it for some customers that requested it. But the user journey is also not great, typically, although at least it's more secure than SMS OTP, and in that regard, it's positive. It's not phishing-resistant, so fraud can still happen. And then we have some additional factors that are more silent in nature. We have some challenge-response factors happening where we recognize the device.
Those we like because, first of all, they don't cost us money like SMS, and as well, the user experience is much better than for something where they have to perform a certain action. Now, this slide is very personal. It's my subjective opinion, so people may disagree with it. But in my opinion, PSD2, when it was written, it was clearly aimed at banks and not so much at e-commerce. Because for the most part, the thought is the issuing bank, the bank that issues a credit card or another form of payment will conduct the SEA and not the merchant.
But because we allow to keep the proceeds in eBay, we are falling under this regulation, and we're not the only company. There are other companies as well. It's typically large companies for sure, but the regulation is often in many regards targeted at banks. And this first bullet point here is subjective. I don't have any numbers of proof to it. But my feeling is that when users are on their bank website, they accept SEA more than when they are at eBay. First of all, they realize this is my bank. This is my money.
It's okay that if it's a bit slower until I can access it or make a wire transfer. But I also want to make sure that this money is secure and nobody can steal it.
At eBay, people also have that money there, but it's typically much lower amounts. And they don't realize that even if they don't have it, we still have to do some of this SEA as soon as they're a European seller.
And also, I think another difference between a bank and an eBay or any e-commerce website is the time you spend on a website. Let's see, what do you do when you go to your bank account or your banking app? You want to check your balance, or you do a wire transfer. That's it. It takes one minute. When you go to eBay or Amazon or any other e-commerce website, maybe you spend 20 minutes there. You want to browse pants, shirts. You want to check if you're a seller. You check what was the sales transactions last month, download the tax statements. And all of them, each of them triggers SCA.
And then while the regulation allows some exemptions, our users, in particular our sellers, will still see a lot of these SCA. And they may drop off, be annoyed. There's friction, and that's not good for our business. Then there's some requirements, like dedicated interface. I'm not going to go in details what that means. If you're interested, read the regulation. It's basically some APIs that can be used by third parties. The idea was that third-party providers, which are regulated in Europe. Plate is one example, one company that comes to my mind.
If you have multiple bank accounts, this app can check the balances in all of these different banks and have a single application. Or you can have reports from these multiple banks. The business model is completely different. We don't just wire money. There's always a transaction going in order. I buy an item. So many of these APIs, none of these TPPs will ever be interested in making business with us.
At least, we have not seen any. But we're still required to implement all of this. So this is where I think, and the question came up in the panel before, where regulations go too far and don't consider all the use cases. I brought up the differences between UK and EU. I'm not going to go through all of this here, but some of the differences are subtle. The European version requires for these third parties that you do a re-authentication every 90 days. The UK says it's fine to just ask the user again for consent, but they don't have to do the actual SCA again.
Or how behavioral data and biometrics are considered as valid SCA factor is different. The UK is typically more flexible. The regulator in the UK, I should say, the FCA, is more flexible.
Also, the end-to-end biometrics, which some of the vendors here are offering here, is accepted. Well, that's accepted as SCA factor, but the local biometrics, which you all see on your iPhones or Android to unlock the phone or to use a passkey, the Europeans have some doubt whether that would be accepted as biometric factor. Those are some things that complicate it. You have to deal with different regulators and slightly different laws. I have to talk to two different lawyers and two different managers of our payment license holders. It makes this whole topic a lot more complicated.
Accessibility is another topic. You can't, as an e-commerce company that is required to implement this, just add one or two SCA factors and say, we're done, these are the most secure ones, we're okay. But we need to think about cases where some users have disabilities, they cannot see as well. Like a CAPTCHA or an SMS OTP, where you need to be able to see it, might not be a suitable factor for them. Or someone who is impended mentally and cannot understand complex transactions or complex ways of doing an SCA. There are several laws that address this.
The European Accessibility Act is certainly the one that is more explicitly pointing this out. It's going to come into effect very soon. I think end of next month. And PSD3 will also include those from what I've read, requirements in terms of accessibility. This article that I cited showed some samples, which kind of factors could work for which type of disabilities. And so it means that as a company you have to offer a lot more different factors. And really think about for which disability can users still use another factor and have the choice to select it. The table is not the full one.
The link on the previous page, if you're interested, you can have a look at that. Another area where regulations potentially can impact SCA is the European AI Act, which has come into effect last year. There is no direct reference to SCA inside the law. But whenever there's biometrics involved in particular, the AI Act is very limiting usage of high risk AI systems. Now there is an exemption here. I'm going to just read this out. It says AI systems intended to be used to evaluate the credit worthiness of natural persons or establish their credit score are high risk.
With the exception of AI systems used for purpose of detecting financial fraud. Does that mean SCA? We assume so, but it's not quite clear. A tangential question that came up to us is pass keys are highly secure, but they're just one factor, typically possession. But they have kind of the biometrics or the knowledge included in itself. So can you use it as two factors?
In one, we don't do that, but there is one we saw recently. One large financial company is exactly doing that. So it's an interesting question for maybe more for the future for PSD3. Is that some an area where we can reduce friction while still offering a secure environment for the customers?
Finally, PSD3 has been discussed for a long time. It's still in a draft version. Last one was published in 2023 and is expected to come into effect next year. Some expected changes are that at least it has been discussed that two factors can be used of the same bucket. So you could have two possession factors. Although there seems to be the EBA seems to disagree with the European Commission and that one saying this is not secure. There's a good reason why we require this. So I'm not sure if this will come. I'm kind of doubting it. Another one is the accessibility requirements that I mentioned.
That's certainly, I think, something positive because it includes more people that can use such websites. Not mobile-only SCA factors, meaning a lot of these factors require a phone. But not everyone wants to have or has a mobile phone.
Sure, it's the large majority, but I bet on eBay we have customers who don't and who still want to shop on eBay. IBAN and name matching is another example. So currently when you make a wire transfer and you have the IBAN and the name, I always intuitively assume they would be matched. And check that the IBAN you wire this money to belongs to this person or this company. But it's not the case. And so this matching will be required. This is the last slide here. I'm not going to talk much about UDI wallets because there's a whole track of talks on this topic here.
But in 2026, as you heard in those talks, European countries, each one will issue their own wallet. Of course, there are also private wallets that have to adhere to that new standard. And then in 2027, UDI wallets must be accepted for SCA. And that includes us. So we as one of e-commerce companies will have to implement wallets at least for SCA. We also see benefits.
It's not just that we have to do it, but we like it because for know your customer, meaning the onboarding or registration of users, it can be a much better experience if we can trust the values instead of having those microtransactions that you may have seen, when two transactions will be done, one cent and seven cent, and you have to enter those numbers, and it takes days to complete. Just as one example, if you have, you could make a much better customer experience, and we could have a higher trust into the information that the customers give us.
And forget your password is another flow where I think this could be great. Forget your password is always the weakest flow. You can have pass keys and everything. And then they go to forget your password, and it's like what's your mother's maiden name and in which city were you born? And then it all falls apart.
Yes, you can add some, let's say you can create a pass key, but that means users need to be enrolled. We already have millions of users that don't have anything enrolled, any information other than their phone number and maybe their e-mail that we can ask. But if they can just use their PID to prove who they are, we could reset their pass keys or send them a new password. So that concludes my presentation. Do you have any questions? All right. Thank you. Any questions from the audience? There's one. Let me grab a microphone. Yeah. I saw you. I'm coming. Here.
Maybe not so much a question, but something you might comment on. I'm from Scandinavia, and the peer-to-peer payments app we all use is something called VIPS Mobile Pay in that area. They onboard you with the EID, so now they have substantial evidence that you are who you claim to be. And the next thing is they use the biometrics of the phone every time you approve a payment. So that seems to be what you were describing.
Yeah, absolutely. Okay. And those are, you know, European legislation applies, or PS2 applies. Okay.
Okay, perfect. Any other questions?
Sorry, it may go like a discussion, but we've talked with VIPS, and this is misleading. They use bank ID to verify their identity. But they have, after we have checked what they do, it seems a good technical setup. But they told us in Britain this shouldn't be treated as substantial method. It's a low level of assurance from their perspective. They have separate payment system and separate authentication system. That's by VIPS. That's what they have told us. But that's a very common misunderstanding. We've heard this from the business coming to us and saying, let's use VIPS. It's substantial.
We have checked carefully with them. They told, no, you shouldn't treat it as substantial. Sorry. You mentioned that in PSD3 two similar factors may be permissible. Has there been any discussion about the use of two biometric factors rather than two possession factors?
Yeah, that's what I meant. I should have said it that way. The discussion was, can we allow two factors of the same bucket, two inheritance factors, two knowledge factors? So it could be two biometrics. But the question is, will this be in the regulation or not? All right. Thank you. There's another question. Can I have the microphone? Thank you. There you go. Great presentation. One question. Paper recently pushed for a more outcome-based form of strong customer authentication. What's your personal stance and eBay's stance on it? Can you clarify what you mean by outcome-based?
I think it's in the direction of not having two factors from the same categories or from different categories, but more focusing on getting phishing down or more on the outcome of SCA. I'm not sure I 100% understand, but let me try to answer it. So we're definitely evaluating all the time as well, like which factors are the most secure and which also at the same time the least friction. And so we're always exploring this so we can, while remaining compliant and assuring high security for our users, we want to make it easier. So I think that's definitely our goal as well.
And we're observing certainly the competition. Well, PayPal is not a competition. It wasn't even part of eBay at some point. But we observe other companies very closely what they're doing. Was that helpful for the question? Okay. Thank you. Let's give it up for Ulrich.
