<div dir="ltr"><div>Hello Anders, inline</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 10:03 AM Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com">anders.rundgren.net@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Francis,<br>
<br>
Can we take this slowly to not create unnecessary friction or hardships?<br>
<br>
I am claiming that:<br>
- On-line banking applications usually call bank-servers directly.<br></blockquote><div>Yes. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Such applications use some kind of API that in the end presumably does quite similar things as Open Banking APIs.<br></blockquote><div>Yes. But the first party. Consuming and producing side are controlled by the bank. So less risks.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Such applications are neither TPPs nor regulated.<br></blockquote><div>Yes. For the same reason. Online banking application is produced by the bank. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Such applications use authentication solutions that the bank consider sufficient.<br></blockquote><div>Yes. For the same reason.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- FIDO is currently held as the state-of-the-art for user authentication.<br></blockquote><div>Yes. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- FIDO is not a PKI solution.<br></blockquote><div>Yes. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If any of the above is wrong, feel free to correct me.<br></blockquote><div>All correct. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What I'm proposing is that it might be useful if such applications could reuse the core of Open Banking APIs. This obviously needs another "input channel" since the security model is entirely different.<br></blockquote><div>The open banking security model is different because open banking is a public API (Open). Online-Banking APIs are private APIs...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Since on-line banking as well as mobile wallets are not standardized, I'm only proposing a standardized mechanism [1] for connecting trusted bank-local applications to Open Banking APIs.  BTW, a trusted bank-local application may very well support a PSD2 compliant service.<br></blockquote><div>Why shall they? Remember mandatory open banking does not contribute to the happiness of banks.  For now, banks have no reason for routing their online banking to open apis.</div><div><br></div><div>Someday banks will understand the importance of open api, extend those api to cover the rest of non mandated services and let customers use free market apps to access their banking services. This time is still to come.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
You claim that the Berlin Group cannot introduce this due to regulatory requirements.<br></blockquote><div>Nothing to do with regulatory requirements. Berlin Group is helping banks discover that path.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Since the Berlin Group is a member-driven organization shouldn't this be up to the members to decide?<br></blockquote><div>Yes. Members are banks and they have their own pace. Unfortunately they sometimes have to move at the pace of the regulator. But they are moving. They need time.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
OBIE is different because they got substantial government funding.<br></blockquote><div>Still not further. Same problems in the UK. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
FAPI is not bound by regulatory requirements and are thus free developing stuff that doesn't necessarily fit OBIE and CMA.<br></blockquote><div>Yes. FAPI is doing that. Still their output has to be consumable in a regulated environment like PSD2, this is why they take care of listening to the market.</div><div><br></div><div>Best regards.</div><div>/Francis</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best<br>
Anders<br>
<br>
1] <a href="https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf#page=7" rel="noreferrer" target="_blank">https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf#page=7</a><br>
<br>
On 2020-07-24 20:44, Francis Pouatcha via Openid-specs-fapi wrote:<br>
> Hello Anders, Nat, Ralph,<br>
> <br>
> There are a lot of reasons why the PSD2 directive mandates qualified certificates (QWAC, QSeal) for access to open API. None of these reasons is technical. The PSD2 legal framework sets up liability models between TPPs and Banks by law.<br>
> <br>
> Open Banking Legal Contract:<br>
> This PSD2 legal framework obliges a bank to accept a request sent by a TPP, without prior establishment of any sort of contract between these two parties.<br>
> <br>
> Secure Connectivity:<br>
> As we know banks are not experienced with operating public APIs. Mandating a bank to accept requests from unknown sources is exposing the bank to risk of foreing sources. The best technical way of closing those public APIs from unwanted request sources is to introduce mutual TLS with a limited class of client certificates. This is what QWAC is designed for.<br>
> <br>
> Liability Management and Non Repudiation:<br>
> In case an initiated payment ends up being qualified as fraudulent:<br>
> - Some entities will have to bear the damage. This is not the PSU but either the TPP or the Banks. For this TPP needs some sort of liability insurance. The same thing legislators require from car holders (In public road & infrastructure sharing contracts).<br>
> - For a bank to make sure the payment initiation request came from the TPP, Bank needs some sort of non repudiable proof that the request came from that TPP . This is what the QSeal is designed for.<br>
> <br>
> Certification of TPPs<br>
> The purpose of regulating TPPs is to make sure they do their homework in the open banking legal contract. It is proof the TPP has his liability insurance, has done his GDPR home work, has verified the merchant on which behalf he is initiating payment. If a bank receives a payment request from a merchant/tpp, how does the bank knows that this merchant is not a scam? As the bank is required not to have any prior relationship with the merchant/tpp, the bank has a way of checking that due diligence has been taken care of by the regulator.<br>
> <br>
> Criticizing PSD2 for not exposing banking APIs to mobile phones is sort of naïve.<br>
> <br>
> Best regards,<br>
> /Francis<br>
> <br>
> <br>
>     Message: 1<br>
>     Date: Fri, 24 Jul 2020 08:04:19 +0200<br>
>     From: Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>>><br>
>     To: Financial API Working Group List<br>
>              <<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a>>><br>
>     Cc: Dave Tonge <<a href="mailto:dave.tonge@momentumft.co.uk" target="_blank">dave.tonge@momentumft.co.uk</a> <mailto:<a href="mailto:dave.tonge@momentumft.co.uk" target="_blank">dave.tonge@momentumft.co.uk</a>>>, Nat Sakimura<br>
>              <<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a> <mailto:<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a>>><br>
>     Subject: [Openid-specs-fapi] FAPI meeting request - Mobile app access<br>
>     Message-ID: <<a href="mailto:336dee65-3e88-f094-77b3-a783527e51c6@gmail.com" target="_blank">336dee65-3e88-f094-77b3-a783527e51c6@gmail.com</a> <mailto:<a href="mailto:336dee65-3e88-f094-77b3-a783527e51c6@gmail.com" target="_blank">336dee65-3e88-f094-77b3-a783527e51c6@gmail.com</a>>><br>
>     Content-Type: text/plain; charset=utf-8; format=flowed<br>
> <br>
>     Hi FAPIers,<br>
> <br>
>     Currently FAPI methods are only accessible by TPPs.<br>
> <br>
>     This may be "by design" but it also makes the API less universal and force banks to create competing APIs.<br>
> <br>
>     As an example some mobile wallets provide real-time account balances.  This obviously requires a direct call to the associated bank.<br>
> <br>
>     Could we have a meeting on this topic?<br>
> <br>
>     Sincerely,<br>
>     Anders Rundgren<br>
> <br>
> <br>
>     ------------------------------<br>
> <br>
>     Message: 2<br>
>     Date: Fri, 24 Jul 2020 15:20:31 +0900<br>
>     From: Nat Sakimura <<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a> <mailto:<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a>>><br>
>     To: Financial API Working Group List<br>
>              <<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a>>>, Anders Rundgren<br>
>              <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>>><br>
>     Subject: Re: [Openid-specs-fapi] FAPI meeting request - Mobile app<br>
>              access<br>
>     Message-ID: <d7423ae5-4bb2-4068-afa0-0d0ec424bf59@Spark><br>
>     Content-Type: text/plain; charset="utf-8"<br>
> <br>
>     Hi.<br>
> <br>
>     Certainly we can take it up as an agenda item but I would like to understand what you mean by FAPI methods. Could you please elaborate on it?<br>
> <br>
>     Nat Sakimura<br>
>     Chairman, OpenID Foundation<br>
>     <a href="https://nat.sakimura.org" rel="noreferrer" target="_blank">https://nat.sakimura.org</a><br>
>     2020?7?24? 15:04 +0900?Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>>>????:<br>
>      > Hi FAPIers,<br>
>      ><br>
>      > Currently FAPI methods are only accessible by TPPs.<br>
>      ><br>
>      > This may be "by design" but it also makes the API less universal and force banks to create competing APIs.<br>
>      ><br>
>      > As an example some mobile wallets provide real-time account balances. This obviously requires a direct call to the associated bank.<br>
>      ><br>
>      > Could we have a meeting on this topic?<br>
>      ><br>
>      > Sincerely,<br>
>      > Anders Rundgren<br>
>     -------------- next part --------------<br>
>     An HTML attachment was scrubbed...<br>
>     URL: <<a href="http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200724/f46e2608/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200724/f46e2608/attachment-0001.html</a>><br>
> <br>
>     ------------------------------<br>
> <br>
>     Message: 3<br>
>     Date: Fri, 24 Jul 2020 06:30:25 +0000<br>
>     From: Stuart Low <<a href="mailto:stuart@biza.io" target="_blank">stuart@biza.io</a> <mailto:<a href="mailto:stuart@biza.io" target="_blank">stuart@biza.io</a>>><br>
>     To: Financial API Working Group List<br>
>              <<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a>>><br>
>     Cc: Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>>>, Nat Sakimura<br>
>              <<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a> <mailto:<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a>>><br>
>     Subject: Re: [Openid-specs-fapi] FAPI meeting request - Mobile app<br>
>              access<br>
>     Message-ID:<br>
>              <<a href="mailto:SG2PR04MB2998548590900E00D0C1106BA7770@SG2PR04MB2998.apcprd04.prod.outlook.com" target="_blank">SG2PR04MB2998548590900E00D0C1106BA7770@SG2PR04MB2998.apcprd04.prod.outlook.com</a> <mailto:<a href="mailto:SG2PR04MB2998548590900E00D0C1106BA7770@SG2PR04MB2998.apcprd04.prod.outlook.com" target="_blank">SG2PR04MB2998548590900E00D0C1106BA7770@SG2PR04MB2998.apcprd04.prod.outlook.com</a>>><br>
> <br>
>     Content-Type: text/plain; charset="utf-8"<br>
> <br>
>     Hi Anders,<br>
> <br>
>     I'm confused. FAPI is a profile on a number of specs and can be implemented by any party without constraint courtesy of the OIDF IPR.<br>
> <br>
>     What an individual ecosystem chooses to enforce as far as membership requirements is up to them but this doesn't seem like part of the FAPI remit? Case in point is that the FAPI spec does not currently provide specific guidance on admission control.<br>
> <br>
>     Stuart<br>
> <br>
>     ?On 24/7/20, 4:04 pm, "Openid-specs-fapi on behalf of Anders Rundgren via Openid-specs-fapi" <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists.openid.net</a> <mailto:<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists.openid.net</a>> on behalf of <a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>>> wrote:<br>
> <br>
>          Hi FAPIers,<br>
> <br>
>          Currently FAPI methods are only accessible by TPPs.<br>
> <br>
>          This may be "by design" but it also makes the API less universal and force banks to create competing APIs.<br>
> <br>
>          As an example some mobile wallets provide real-time account balances.  This obviously requires a direct call to the associated bank.<br>
> <br>
>          Could we have a meeting on this topic?<br>
> <br>
>          Sincerely,<br>
>          Anders Rundgren<br>
>          _______________________________________________<br>
>          Openid-specs-fapi mailing list<br>
>     <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a>><br>
>     <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
> <br>
>     ------------------------------<br>
> <br>
>     Message: 4<br>
>     Date: Fri, 24 Jul 2020 06:37:37 +0000<br>
>     From: Ralph Bragg <<a href="mailto:ralph.bragg@raidiam.com" target="_blank">ralph.bragg@raidiam.com</a> <mailto:<a href="mailto:ralph.bragg@raidiam.com" target="_blank">ralph.bragg@raidiam.com</a>>><br>
>     To: Financial API Working Group List<br>
>              <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>>>, Anders Rundgren<br>
>              <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>>><br>
>     Cc: Nat Sakimura <<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a> <mailto:<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a>>><br>
>     Subject: Re: [Openid-specs-fapi] FAPI meeting request - Mobile app<br>
>              access<br>
>     Message-ID:<br>
>              <<a href="mailto:LNXP265MB0809FDF99C26121A73039FB2F6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM" target="_blank">LNXP265MB0809FDF99C26121A73039FB2F6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM</a> <mailto:<a href="mailto:LNXP265MB0809FDF99C26121A73039FB2F6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM" target="_blank">LNXP265MB0809FDF99C26121A73039FB2F6770@LNXP265MB0809.GBRP265.PROD.OUTLOOK.COM</a>>><br>
> <br>
>     Content-Type: text/plain; charset="iso-2022-jp"<br>
> <br>
>     Hi Anders,<br>
> <br>
>     Further to Nats questions, there is nothing stopping a confidential client being run on a mobile device. Indeed this is how a lot of Banks Mobile applications are written. With a confidential client on a mobile device there is nothing stopping the app from interacting with a providers APIs using the FAPI Security profiles.<br>
> <br>
>     Joseph calls this out explicitly in implementation guidance section however there are significant challenges for implementation of this model under PSD2. The use of qualified certificates for 'identification' makes this almost impossible for a TPP to do safely or at least in a way that would be appropriate from a risk point of view however, if a TPP wanted to do this they could.<br>
> <br>
>     Be interested to know where the specs technically don't work for confidential clients on a mobile.<br>
> <br>
>     RB<br>
>     ________________________________<br>
>     From: Openid-specs-fapi <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists.openid.net</a> <mailto:<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists.openid.net</a>>> on behalf of Nat Sakimura via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>>><br>
>     Sent: Friday, July 24, 2020 6:20 AM<br>
>     To: Financial API Working Group List <<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a>>>; Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>>><br>
>     Cc: Nat Sakimura <<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a> <mailto:<a href="mailto:nat@sakimura.org" target="_blank">nat@sakimura.org</a>>><br>
>     Subject: Re: [Openid-specs-fapi] FAPI meeting request - Mobile app access<br>
> <br>
>     Hi.<br>
> <br>
>     Certainly we can take it up as an agenda item but I would like to understand what you mean by FAPI methods. Could you please elaborate on it?<br>
> <br>
>     Nat Sakimura<br>
>     Chairman, OpenID Foundation<br>
>     <a href="https://nat.sakimura.org" rel="noreferrer" target="_blank">https://nat.sakimura.org</a><br>
>     2020?7?24? 15:04 +0900?Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a> <mailto:<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>>>????:<br>
>     Hi FAPIers,<br>
> <br>
>     Currently FAPI methods are only accessible by TPPs.<br>
> <br>
>     This may be "by design" but it also makes the API less universal and force banks to create competing APIs.<br>
> <br>
>     As an example some mobile wallets provide real-time account balances. This obviously requires a direct call to the associated bank.<br>
> <br>
>     Could we have a meeting on this topic?<br>
> <br>
>     Sincerely,<br>
>     Anders Rundgren<br>
>     -------------- next part --------------<br>
>     An HTML attachment was scrubbed...<br>
>     URL: <<a href="http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200724/9ed40c0b/attachment.html" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200724/9ed40c0b/attachment.html</a>><br>
> <br>
>     ------------------------------<br>
> <br>
>     Subject: Digest Footer<br>
> <br>
>     _______________________________________________<br>
>     Openid-specs-fapi mailing list<br>
>     <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a> <mailto:<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a>><br>
>     <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
> <br>
> <br>
>     ------------------------------<br>
> <br>
>     End of Openid-specs-fapi Digest, Vol 210, Issue 3<br>
>     *************************************************<br>
> <br>
> <br>
> <br>
> -- <br>
> Francis Pouatcha<br>
> Co-Founder and Technical Lead<br>
> adorsys GmbH & Co. KG<br>
> <a href="https://adorsys-platform.de/solutions/" rel="noreferrer" target="_blank">https://adorsys-platform.de/solutions/</a><br>
> <br>
> _______________________________________________<br>
> Openid-specs-fapi mailing list<br>
> <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Francis Pouatcha</div><div>Co-Founder and Technical Lead</div><div>adorsys GmbH & Co. KG</div><div><a href="https://adorsys-platform.de/solutions/" target="_blank">https://adorsys-platform.de/solutions/</a></div></div></div></div></div></div></div></div></div></div></div>