 dir vielleicht auch so ein Smartphone. Und ich habe da so eine App drauf. Und damit, ich habe so mehrere Konten bei verschiedenen Banken und ich habe so eine App, da sind die ganzen Konten so drin und wenn ich wissen, wie viel Geld ich nicht habe, dann starte ich diese App, dann gucke ich da so drauf, weil mein Telefon mich sonst nicht erkennt und dann kann ich halt sehen, wie viel Geld ich auf dem Konten habe und was ich so für Kontobewegung hatte und dann irgendwann dieses Jahr habe ich da nicht mehr gesehen, wie viel Geld ich auf dem Konto hatte, sondern da kamen immer so Pop-ups. Die haben gesagt, ja, das funktioniert jetzt nicht, weil habe ich nicht verstanden. Aber was da immer drin vorkam, das waren drei Buchstaben und eine Zahl und das ist PSD2. Und jedes Mal habe ich gedacht, jetzt muss ich wieder aus der App raus und muss wieder irgendwas machen, was ich nicht verstehe und dann werden mir SMSen geschickt, die ich irgendwo eintragen muss und dachte die ganze Zeit, was zum Teufel soll dieser Scheiß. So, und das Schöne ist, wir alle werden jetzt möglicherweise eine Antwort auf die Frage bekommen, was dieser Scheiß soll und falls nicht, dann können wir ihn hinterher persönlich zur Rechenschaft ziehen, seinen Namen, ja genau, also ich habe, ich versuche die Frage zu stellen, was die PSD2 je für uns getan und Antworten darauf zu geben, in der Hoffnung, dass ich dann auch rausfinde, was der Scheiß soll. Für diejenigen, die, es ist hier einer der ersten Vorträge, für diejenigen, die hereingesteuert sind, ohne zu wissen, worum es geht, es geht um die Richtlinie der EU 2015, 2066 des Europäischen Parlaments und des Rates vom 25. November 2015 über Zahlungsdienste im Binnenmarkt zur Änderung der Richtlinie und so weiter und so fort und so fort. Das ist die, das ist die Zahlungsdienste Richtlinie 2 und daran hängt noch eine Handvoll delegierte Verordnung, aber ganz massiv die delegierte Verordnung vom 27. November für die technischen Regulierungsstandards für eine starke Kundenautentifizierung und für sichere offene Standards zur Kommunikation. Das ist was in der App die ganzen Pop-ups verursacht hat. Warum bin ich hier und warum erzähle ich euch was zu diesem Thema? Ich bin Informatiker und Sicherheitsforscher, ich glaube neudeutsch sagt man Hacker dazu, habe meinen, einen meiner ersten Vorträge auf dem Kongress vor zehn Jahren zu Meiver Classic gehalten, seitdem einiges gemacht zu Zutrittskontrollsystemen, RYD, Spezialgebiet sind halt solche Arten von Kommunikationsprotokollen. Ich bin auch Open Source Entwickler, also wenn irgendein Kommunikationsprotokoll rumliegt, dann implementiere ich das manchmal. Unter anderem HBCI, dazu erzähle ich euch noch ein bisschen was. Es gibt im Umfeld des CCC eine Vereinsverwaltung, die entstanden ist, die heißt Biro von Rix. Da habe ich einige größere Dinge zu beigetragen und es gibt von Rami, die beiden waren ja hier die Kasse und den Vorverkauf von Rami eine Peißen-Implementierung von Fintes. Ich sage euch gleich noch was das ist. Dazu habe ich größere Dinge beigetragen und dann die Kombination dabei ist das Plug-in Biro Fintes. Also eine Perspektive, aus der ich das betrachte, ist halt als Open Source Entwickler. Ich bin auch Gründer und Geschäftsführer. Vor zwei Jahren habe ich mit Freunden zusammen meiner eigene Firma gegründet, die Digital Wolf Plötz und Co. GmbH. Wir haben ein etwas schwammiges Selbstverständnis oder eigentlich sehr präzise Selbstverständnis, das etwas schwieriger zu verstehen ist. Das ist die Digitalisierung in komplexen Umfeldern. Wir machen halt Beratung, aber entwickeln halt auch Software. Aus dieser Ebene gucke ich das auch an. Beziehungsweise andere Produkte für die evangelische Kirche bauen wir den digitalen Klingelbeutel. Wir sind jetzt Zahlungsdienstleister. Zum Glück hat es nichts damit zu tun. Ich bin, ich freue mich sehr, dass alles was wir tun an der PSD2 vorbeigeschrammt ist, außer halt als Privatkund. Ich bin nämlich auch noch neugieriger Nutzer. Wir haben gerade in der Einführung gehört, dass jemand durchaus eine App in mehreren Konten haben könnte. Ich habe mal kurz durchgezählt. Bei mir sind es neun verschiedene Kunden, weil ich auch noch mehrere Hüte auf habe. Also sowohl Geschäftskonten, nein, neun verschiedene Banken. Konten sind es ein paar mehr. Als sowohl geschäftliche Konten als auch Privatkonten beziehungsweise Familienkonto als auch, ich bin in einem Verein Vorstand, Vereinskonten. Ich glaube sieben oder so davon benutze ich auch regelmäßig. Der Rest war halt so kostenloses Girokonto. Man ausprobieren, was die tun und dann sind da halt zehn Euro drauf und man kann sehen, wie die auf diese Umstellung reagiert haben. Das hilft dann auch wieder beim entwickeln von Open Source Software, wenn man Testkonten hat und mal gucken kann, was die Banken so anstellen. Agenda. Also wir haben gerade gehört, worum es gehen soll. Ich werde euch gleich den wunderschönen Vorherzustand darstellen. Situation beforehand. I will give you a reason from the European Commission why this directive was published. Then I will answer the question, what has the PST to ever done for us in the nice form in the intended form and then in what actually happened. I will talk about the chronology of the whole thing and the several problems and nuisance that came with it. I greatly appreciate it two minutes before this talk I saw an advertising slide for BTX. There are BTX terminals here at Congress. Not everything was bad in the 80s. There was online banking for private customers. In Germany this started sometime in the early 80s. I think the CCC has some history with BTX, people might remember. In 2007 this was finally turned off, but worked pretty well. From this Sprang to Life HPCI, the Home Banking Computer Interface, which is a communication protocol used to exchange banking data for end users. It's basically comma separated values on steroids, but sometimes other signs like a plus character can be separators. I did implement it. It's actually parsable. There are protocols that are not parsable. This is not one of them. I was surprised. I thought it's mainly a coincidence, but it works. It's mainly a hierarchical data structure, but there's only three layers of separators. At some point the separators are at the end of the separators, but that's also the end of the layers. This was later, this was implemented in 1998, Version 2.1, I believe was the first usable version. It was then improved further and further up to the point where 3.0 is known by many people and was then renamed to FintiS, Financial Transaction Services. It's a purely German thing. With FintiS there was an attempt to make this internationally usable. For example, by pouring this into XML. Even the XML is parsable, but I would say it's one of the ugliest implementations that you can imagine. There's also no one who uses it. Well, that's not correct. There's a central list of all the banks that support and the FintiS and HPCI versions they support. In Germany you can basically reach every bank, for example the Deutsche Bank with Version 2. Most support Version 3. I think there's exactly one bank that supports Version 4. As I said, basically no one uses it. FintiS 3.0 basically everywhere, because that's how it was available to the general public. HPCI was a purely German thing and very secure. You needed a smart card. You needed a pin. You needed a separate contract to get this running. There was even an alternative version where you would send floppy disks in letters and RSI keys in letters. But starting from FintiS 3.0, there's an alternative Login pattern called Pintan. You log in using your Pintan and whenever you wish to affect a transaction, you need to use a transaction authorization number. It's very nice. It works, but it will soon die, unfortunately. The French have something similar. It was called Minitel, but it was turned off a couple of years ago. Roughly, that's it. There is in well-structured formats. I also added a screenshot from Wells Fargo, sometime in the 90s. That was before HTPS. This spawned a wild growth of web banking systems, where banking would run through a web interface, always in different protocols, always with slight differences, so no structured format. For corporate customers, this looks a bit different. All of what I talked about was private. For business customers, it looks a bit different. It started with sending floppy disks in the mail back and forth, later on things like BCS and eBix, which I will talk about in a minute, when I talk about the situation in my company, because this is a shame with FintiS. Back in the day, this allowed for interoperable eBanking. There's a set of business cases defined in the FintiS specification. You can access your account statements. You can access lists of transactions. You can send transfers. There's a bunch more. A lot of banks have other systems, but most of this works kind of everywhere, whether it's an app on a smartphone or a software on a computer. The cool thing was, this was more or less universally accessible. It used to be released by the ZKA, which was later renamed to DKA, die Deutsche Kreditwirtschaft, the German credit economy. You can download the spec from DKA. It's generally parsable. I did it. All you need afterwards is a username, a PIN, and the same credentials that you use for eBanking. I think the most important thing, you don't have to ask anyone before you write an implementation. You don't have to ask anyone in order to use an implementation. I did this for an association management system, making sure that payments in that association were automatically parsed and transmitted. The nice thing about FintiS is that it's forward compatible. It has singular records, which are equipped with a version. You can add new versions of a given record. The bank can support a given version. A thing is, this may change whenever there's new regulation, so there might be a new version of a credit statement or for any given record with a new version. For example, at the point where there wasn't a e-directive stating that customers had to provide the account number where the cost of a TAN code was to be charged to, you can tell from the version increments of the specification when such directives went into effect. As I said, the most important feature was multibanking. You could have an application on your computer or your smartphone and access all of your accounts in that. In addition to that, what other kind of systems were out there were related to online shopping, I want to pay for an online transaction. So there's still things like PayPal, wallet services, which you charge with a given amount of money that are disconnected from your account. There's also a group of services that connect directly to your account. The easiest of those systems is payment in advance. So you pay ahead of receiving whatever you ordered. There is collect on delivery. Sorry, that was wrong. There is a direct debit or direct withdrawal services. There are some connected systems like Ideal in the Netherlands, which is where the merchant talks to an interface at the system, asks for a given amount of euros from a given user and doing that on the website of the bank. The user authorizes the transaction. The merchant immediately receives the authorization for that transaction and can immediately send the goods. We have something similar in Germany. It's called JiroPay and no one knows it, because I think it's only the Sparkase, who uses it, and no one else apparently. In parallel, starting around 2006 or so, a company sprung into life called Sofortüberweisung and sometimes we kind of wonder how something like that could come to be. I've always found the business model a bit odd. This is Sofortüberweisung in the middle. The user gives their credentials that he received from the bank. He enters those in the website of Sofortüberweisung. Sofortüberweisung logs into the banking website. Sofortüberweisung then tells and affects the transaction on the banking website. Then it gives the transaction authorization to the merchant. Sofortüberweisung promises the user not to do anything else than to actually send this specific one transaction and not to snoop around in the account or do anything else. But there is no technical guarantee. They did receive a quality check from TÜV and at some point they also added the point where they had insurance. So in case something went wrong, they seemed to have insurance. Around 2012, the conditions of participation of many banks started including a clause where they asked the user to sign that they only give their credentials directly to the bank over a secure connection. So what I did to illustrate the whole problem was I searched for a picture from Wikipedia. So kind of what you're doing is you're violating your bank's conditions. The bank doesn't guarantee that this is going to work and the bank will not cover any damages that you may incur. There were a bunch of banks that tried to take technical measures to stop this from happening. I haven't don't have any evidence, but I think I heard something about the Sparkhazis stopping accesses by blocking a bunch of IP addresses, resulting in Sephardipa Waisung connecting from different IP addresses shortly thereafter. This might also have been a business decision because the Sparkhazen did have their own competing system. So as a result, they were forbidden from interfering with Sephardipa Waisung's services. So I tried to check the conditions of participation for my account and what happened is they changed the details in the conditions of access and they added a sub clause with a comma saying, you can only enter your credentials on the secure side of DKB or on the list of other authorized providers, including only Sephardipa Waisung. To have a look at this, I had to log in to the DKB account at some point to receive my account messages. In order to do that, I had to generate a tan, which is generated in an app that receives a password to do that. In order to reset the password, which I had forgot, I had to send myself a text message, which was easily done. So I don't think I really have to remember the password because it's the same flow as a normal login. So this is the state until mid this year or so. 2015 PSD2 was published and these are the the rationales for why it was published. The antecent before it was in 2007 the old payment services directive using mostly the services that trigger payments as a rationale for why the original PSD was published, as well as account information services. The idea was to make sure that the market should remain in continuity, so it should provide some security against market disruption. This is a side-by-side view of these two directives. They have some incredibly complex wording that takes you several minutes to figure out that oh, this does not apply to payments in supermarkets. There's an appendix that explains what it relates to and in version two they've added payment services and account information services. So what did PSD2 give us? These new categories of a payment service and account information service. New security measures, which is the part that most people know about. The so-called strong customer authentication. And this is combined with a very strange 19-day rule that nobody really explains. A 90-day rule that nobody really understands or explains. And the time out in online banking was lower to five minutes. So if you fail to click something within five minutes, for example, because you're looking for a 10-Generator, you're logged out and you have to log in again. There is a new transparency requirement for banks. Most people don't notice this because they take the box. But it means that banks need to inform customers about their fees. The fee structure has to be understandable. You have to receive it on a permanent data carrier. And the PSD2 also requires banks to report certain things to the Federal Bank and to register before they start offering their services. Most people seem to think that's pretty good. We had a meeting with the Federal Bank and they thought they should help them. Among other things understand market stability because these services have to, they know which kind of risk assessments they have to have to conduct and in which way they have to report these to the authorities. And there are new interfaces. The payment service directive speaks about dedicated interfaces that these services have to offer. These are called APIs. And this is what PSD2 API is all about. But it doesn't tell, it doesn't say how they're supposed to look, only what they have to do. These new categories, a payment provider is somebody who has services like Zufordüberweisung, that third parties that start, that send payments on behalf of others. And account information services, which is what used to be known as multi-banking. I'm not sure what the people who wrote this thought of, but they certainly didn't have a telephone that offered all this. They had websites in mind. Because these days you're supposed to be able to have a portal that collects all the information about your bank account and lists them on one single page. Let's have a look, let's look at history. I found a screenshot. Oops, this is wrong. It was probably 2016. It's a screenshot from 2016 where they imagined what the future with the Brave New World of PSD2 might look like. Because these days you have to go through a payment provider who then contacts a credit card provider that contacts a bank. And these days the online shops can directly access your customer's bank account. Well, no. I call it the third party lie. This is what it looked like in our company. We had staff software, accounting software, wage apps. These spoke to my bank via Fintes. It's a computer that sits in my office. I own it. And it connected my bank, which I trust. And I give them my account details. And it works very well. This stopped working on the 14th of September 2019. Dathef told us that they have a new cooperation partner, which is called the Fint API, GmbH. So my account details go to Dathef's computers. They send them on to Fint API. And they then contact my bank. I like the Fint API logo because it says a Schufa company. It's now it was bought by the Schufa Holding, which is a German credit scoring company. So in this Brave New World all my data goes through Schufa. And of course they say they don't use it for anything evil. But at the same time I never entered into a contract with Schufa. My contract is through somebody else. So it's not very nice. But everybody speaks about these third parties implementing these APIs. It's always four parties though. It's me. It's always me and my bank. Of course, that's two parties. Then there's one something that I really want to do. For example, payments would be a third party. But in fact, there's always a fourth party, a gatekeeper implementing the API. I'll tell you why, but it's essentially because these get preferred access to all the banks, which isn't easy to implement on the other two layers. There's always a fourth party. There's no use case that I can imagine where it's only three parties, except perhaps for the Account Information Service that operates these portals where I can get an overview of several accounts. The PSD2 API calls for an Open Access, where Open is meant in the way that bureaucrats understand it. There are no contracts required between the banks and the people who use these APIs. They're required to offer an API. But it only says that it needs to be available and what it needs to do. And it needs to be as good as the other interfaces that the bank offers to the customer. It doesn't actually prescribe which specification it needs to fulfill, which means that, well, not all banks develop their own APIs. They don't fancy doing that. They buy them from external providers. But there's a large handful of different APIs used by different banks. So when I want to implement functionality that accesses accounts, I need to either implement all of these specifications or I use a third party or fourth party that implements all of these for me. There were attempts to specify a PSD2 API that everybody might or banks could implement. The website is a bit awful. It's the quasi standard, but there is no de facto standard yet. To use this API, I have to be a licensed or registered provider. The good news is that there is no requirement to own capital. I can't do it as a private person, but I can do it as a legal person by registering a legal person and buying insurance. But as soon as I want to offer payment services, I need to have several tens of thousands of euros in capital. And most functionality that I can imagine don't really make sense with just account information. So, for example, if I have, if I organize payments for a club, I want to be able to both register that people have paid me, but also pay others. And the access is open as long as I have an electronic certificate that proves my identity. The concept of software that you run on your own computer and not in the cloud doesn't exist in this legal document. It's completely useless for people who want to run software on their own computer. The new thing is strong customer authentication, which is the blood pressure thing. This strong customer authentication can be required. And it means that you can require two elements of the Categories, Knowledge, Ownership, and Biometrics. After five failed attempts, the access has to be blocked. The inactivity rule also exists here. There has to be a dynamic link between customer identification and the transaction. So we can't use these transaction number lists. And there have to be mechanisms that ensure that the software or the device has not been tampered with by the person paying or third party. And that's where my blood pressure went up, because of course my devices are rooted so I can do backups. And then the app says, no, you're not allowed, it's rooted. And then when you think about what rooted means, it means that the device can lie about its state. And the app doesn't want that unless the device is so good at lying that the app works after all. So I tried to run this on device that has ways of blocking these attempts of detecting whether or not phones are rooted, but this leads to this arms race. So it means I have a second device where I run the TAN apps that are currently not wanting to be tricked. And then there's another so-called feature surprise SKA. Things were simple this far. I would log in with my pin and that would give me read only access. And as soon as I wanted to write anything, I would have to enter a transaction number. Now I need transaction numbers for a lot more. I sometimes needed to log in. The precise wording is to access sensitive information, except for sometimes. There are four or five pages in the technical directive that explain these exceptions. I'm allowed to not require the SKA when I access transactions that are less than 90 days ago, unless it's the first time or the last time was more than 90 days ago. For contactless payments, payments up to 50 euros that are possible without the pin or the strong customer authentication, unless it was more than 150 euros since last time. Parking fees are always without SKA. Trustworthy payees are allowable without SKA. Recurring payments starting from the second time can be without SKA. Transfers to a different account of the same person can be done without SKA. Small amounts up to 30 euros can be done without SKA, except for sometimes. Some methods used by corporate accounts are included. And transaction risk analysis modifies all this, which means that they can require SKA in places where it was previously accepted or go the other way of requiring it, but not requiring it where it was previously required, unless it determines that there's a high risk of fraud, which means that I'll always be required. This means essentially that I can never know if a ton is going to be required, which means that using interface design is really difficult, because you don't know if a ton is going to be required when you hit submit. It's very confusing for users, because they can't rely on anything. They don't know what's going to happen when they press a button. For authorized services using FinTS, it's completely impossible, because even transactions that I thought were read-only and wouldn't require a ton. For example, Cron jobs that fetch my account, transaction history periodically, these two may require a ton because of some edge case. And when you use a push service, it's great, because the person receiving this ton doesn't know if that was their Cron job, or if it was an attack. These ton mechanisms work in different ways too. So some banks require you to log in. Other banks like the Spark asset don't require you to log in. But for example, Spark asset requires you to enter your password when you want to search for things that go back more than 90 days. There is no consistency between banks here. And you will notice this only ever happens with EU-Directives or regulations. I don't know if you have a PayPal account. PayPal still doesn't have two-factor authentication. They simply do transaction risk analysis, but they know that the tons only lead to the user cancelling the transaction, which is bad for payments, because it means people don't pay. And that's one of the reasons why PayPal don't have, don't use two-factor authentication, and despite criticism, they're still running their services. These are the ton generation apps that I have on my phone. I have recently, after the 14th of September, looked in my press and actualizing all bank accounts. I had to enter nine different tans in four different ways. I had ton generators with chips. I needed to search for those, but that wasn't that difficult, because I only needed it for transactions. The DKB has disconnected the credit cards from this old payment, old system. So, there's a separate ton required. I didn't press and refresh at this one. So, timeline. The directive was introduced in 2015. In 2018, it was put international guidelines. Basically says copy and paste from the guidelines. The directive was called upon the technical regulations in 2017, because there was a deadline on the 14th of September. This was the delegated guideline. Six months prior, banks should have introduced a test API for software developers, so that they could test their products. There was a fallback solution, if you were outside of the PSD2 guidelines. If you had for 30 seconds of long latency, you needed payment service providers to use a fallback that was the interface that the normal customer used. If banks didn't want to do that, they needed to use the PSD2 API 3 months prior. In June, they should have used the PSD2 already, in order to not fall into the fallback. On the 14th of September, everything exploded. The directive came into effect, which led to only certain things to explode. Certain banks only used the 90-day limit. If you were signed in, on the 13th of December, you needed to have those problems. Sign-in flows for two-factor authentication apps were complicated for the post bank. You needed to sign new things for club accounts. It wasn't that bad, because you could share the pin, because only one received the pin for the 10th generation. Everyone needed a single one for access. Post bank needed a signature, and they didn't want to accept emails. They didn't want to accept emails because of fraud, so that made it very difficult. After asking support by phone, they said they were going to ask, I proposed the fax in, but that made it even more complicated. I showed this on the screenshot before. If I have eight different apps, I have to re-sign in eight times. If I wanted to sign in on the Apple Town App, it didn't work to create a new letter. No one knew where to enter the code, and I needed to search for that code on the web page, and it also didn't specify. For credit cards, this also should apply, but no one has implemented it yet. This is why the EBA said that they have an additional timeline until 2020. APIs don't work, then that's because they didn't have enough time to test, they say. There was already a talk about this top pick. There was Mastercard, SecureCode, and Visa card, verified by Visa, and this was basically not that great. 3USCure is Acquiresure and Interoperability. The customer is missing in this list. The whole thing is there to add new terms of participation to customers and basically make the customer liable for whatever damages are there. One group of banks, the VR Banks, part of Viducha, ask you to register on a website on onleinsichereinkaufen.de. Sorry, it was, I'm not quite sure which one it was, but I know, because one of the pages exists, the others don't currently. Currently only this one exists, and has a valid certificate from Let's Encrypt. And then there was the thing about blood pressure, so this said, you can sign up here and turn on Pushtan, but that doesn't work on your phone because it's rooted, it's insecure. You can also use the alternative process though. We'll just send you an SMS, a text message to that phone. Okay, I don't understand this, but fine. So this form here is currently online. It still has the same problems that Mordekan Anderson reported previously. If you scroll down, you'll find this sign up system. It's an iframe, it's from some other domain that has an extended validation certificate, but yeah, no one sees that because it's in an iframe. So what else? Club and family accounts now require one sign up per person. People are having fun with it. The banks are moving to turn off Fintiesk, because they have PSD2 now. Regulated services can no longer use Fintiesk, well, except sometimes in fallback mode. Surprise SCA is tripping up users everywhere and causing high blood pressure. There's one thing that's not too bad. There's no registration requirement for applications, even for Fintiesk, with a goal of transparency. And now in online banking, you actually see which application was used for access to your bank account. But development is still possible for open source developers. But almost every transaction can sometimes require a tan. So, we just saw this, but let's move to the end. Transparenz and regulation were improved. Consumers are kind of annoyed. It's a perfect basis for phishing. I don't know if you received an email saying PSD2 is not in effect, please log in here. Perfect phishing case. Commercial users now have to move elsewhere. The good thing is, there's now new business opportunities for startups that can circumvent that. Finally, open source software and non-cloud applications are mostly excluded. And that's it. Thank you. We have 12 minutes for Q&A. There's three microphones in the room. If you have any questions, please line up. I'll try and distribute fairly. But I have one question. What the fuck? Didn't you hear? Sofort-Überweisung ist now legal. Ah, let's start with you. The question is, you said that Finties is being faced out by banks. I know that some banks have directly turned off Finties. Do you know how this looks like for other banks? Are there any signs from the big providers for banks? In large part, they kept back about this. They don't want to extend this because they have other things to do. I think they turned back. So yes, there's no reason to do that. They got back because lots of people complained. Is there any sort of information sheet or something that as a customer, I can give to the bank, if I have the impression that they're talking complete bullshit at me? It mentions in the directive that European banks have to give out information to customers about new regulations and about requirements and rights to customers. The other way around. The sheet is for you as a customer and you can show it to the bank and pressure them about what isn't included. You said it's not that complicated to start a company with a legal entity. Would that help me to create a company so I can get an API and then access my account? You need a new app. The answer is yes, you need a new app, which runs ebix, but that should work. You listed that there are three ways to, three authentication specifications. You talked about TANs. If I correctly understand the directive, is knowledge and ownership about the chip card. A chip card is still a good auto-finance recognition method. Yeah, that's correct. So from these three factors an authentication needs to be derived. This can be any sort of signature. I have never seen an implementation except for a bunch of apps, though. For example, DKB has its own app and everything stays within that app, including the iPhone, face recognition, and so on. The thing is, if you use a different app, that's not this one. It's difficult to type a signature. So, yeah, you use the TAN. I'm only asking, because Spark has said that HabitCE with chip card is not fulfilling these requirements. Yeah, the statement is incorrect. The card is pin plus card, knowledge and ownership. So, no, this is fine. Only a small annotation. You mentioned that PayPal doesn't support two-factor, but I used two-factor. I think there was, five years ago, there was a short time for where they allowed two factors. I think they stopped there. I could click on this half a year ago. Cool, then they allow it again. Nice. I'm asking for a friend. He develops an online shop and he confuses with this 3D secure thing. Payment service provider says that it's fine to enter the credit card with this 3D secure method. And after that, the shop can withdraw from that credit card as much as they like after that. I'm not quite sure about that. For the first payment for repeating payments, yes, but I think this needs to be confirmed for every payment. I'm not exactly sure, but sometimes simple authentication should be enough. Okay, two factors should be enough. Would you be okay with PSD2 if it was open source? Or are you saying that this is bad? It's relatively difficult to implement these requirements, because most open source users tend to download and compile around their software themselves. I didn't see how it's possible to really support open source. And basically you would have to stop the requirement to have a qualified electronic signature at the endpoints. And then the only problem would be you'd still have to have the TANs at the endpoints. Yeah, it would be feasible. I just wanted to mention that most here will have two bank accounts. But all this two-factor thing is just going crazy. If I have my online banking and the two-factor on the same device and the integration that some banks offer, that was shown in Congress before, this can be hacked very easily. How can we ensure that this has been done securely as a customer and that as a customer you can make sure that this is done well? So it says that there should be two separate devices or if it's on the device, there needs to be a separation. It's somewhere in this routing clause. It needs to be separated by the features of the operating system or something. So I think this moves into the direction of something like Samsung Knox and not default Android. I think also when I accessed that in detail I was on a router device or something. I'm using an open source software to track my finances and I have that on my server. And I am now with that I am a payment service provider. And the developer said he wanted to include PSD2 and he said, and I don't think that's possible, the developer said he registered himself somewhere and I'm not sure if that would work and I'm not sure if I can use that. I'm not sure if you can use that. I have to look it up. I'm not able to answer that. Is he able to include PSD2 in his software? No, he's not able to put that into his software. He needs to use FinTS. You can change the evics. Do you have a suspicion who is behind this? Why did they do that? Soforthe Beweisung? Alone against a bank lobby? Who did propose that? I really don't know. We talked briefly before this. Digital first and second. It sounds like progress, so probably it's better. They thought it sounds better. I just wanted to ask, do you know political organizations or actors who try to summarize, to do lobbying in the name of the users and the clients? I think there's a club of IT users as a register club. So I would just say this is more of a self-help group. No, I just know this one, but nothing else. Last question. You mentioned registration for third-party services. Isn't that kind of an approval for the bar thing? So, in the last few months, the guidelines were published. How can these allowances be withdrawn? I think there are some additional conditions for information providers. This is a bit simpler. Only certain paragraphs apply to them. In other words, it wants to actually trigger transactions. The full security package applies to them. Are you happy? Singularanger has another question. Can I prevent my employer from receiving my bank data? Funny question. Second question. Can you give us a preview whether there's going to be any improvements? So, it says that every X-Years or so this directive is supposed to be updated. I think it's 2022 or something. I'm not very hopeful though, because from the perspective of the central government, non-Cloud services seem to be kind of weird and a niche product. So, it's kind of a question. I'd like to introduce a previous question. There's an institution that tries to improve the situation. I'm working for this in the name of sub-photobereism. We are actively working on this to discuss with European banks and regulators to improve this in the very near future. There are a few people who try to improve the situation. Very good. So, you may be able to answer the question I asked before. Henry Platz, thank you.