 Ok, we are live. Hello, good morning, good afternoon or good evening everybody, depending on when in the world you are joining us in from. So we will just wait for a couple of minutes to get everybody a chance to join and then we will start with our hyperledger in-depth webinar with Instant on enabling portable KYC for financial institutions. We are very happy to have you here and we will get started in just a couple of moments. Hello everyone, good morning, good afternoon or good evening, depending on where in the world you are zooming in from. Welcome to the hyperledger foundation in-depth webinar with Instant on enabling portable KYC for financial institutions. We will get started in just a minute or two to allow more people to join. While we wait, I would encourage everybody to use the chat button, say hello, introduce yourselves and tell us where you're zooming in from. Myself, I'm zooming in from Boston, Massachusetts today. Ok, I think we can get started. Hello again everybody, good morning, good afternoon or good evening, depending where in the world you're zooming in from. Hello Anastasia to Chicago. Welcome to our hyperledger foundation in-depth webinar with Instant. Today we will be looking at enabling portable KYC for financial institutions and we're very excited about today's webinar. My name is Tomas and I'm an ecosystem manager at the hyperledger foundation. Today I will have a chance to take you through some housekeeping rules and introduce our panelists. So if you've ever joined the hyperledger foundation webinars before, you know that we do have some housekeeping rules. First of all, I would like to emphasize that everybody is welcome in the hyperledger community and we strive to create an open and welcoming environment for everybody. So please follow hyperledger code of conduct when interacting with other people in our community on this webinar and more broadly as well. You can find our code of conduct on our wiki and on our web page as well. All hyperledger foundation are held under Linux Foundation Entitrust Policy which you can also find on our wiki and on our website as well. We are recording this webinar and the recording will be available later in our webinar library along with the slides. So if you miss something you can always return there and check the slides and to watch the recording as well. This webinar is also being live streamed on YouTube and linked in live so welcome to everybody joining us there live as well. And as mentioned, slide will also be available in our webinar library so you can always download from there as well. Now we encourage these sessions to be as interactive as possible so we encourage you to stay active and you know the more participation we get the better experience for everybody. So you can use the raise your hands button to get unmuted and to speak up and ask the questions to our panelists directly. You can also use the Q&A box and we will return to the questions at the end of the webinar and you're also welcome to use the chat box which I see it's filling up already to also ask your questions there. Now I'm very happy to introduce our panelists for today. Justine, a Chief Product Officer at Instant and SD, a Vice President of Engineering at Instant. Now without further ado, Justine and SD, over to you. All right, thank you Thomas. I'll share my slides and we'll get going here. Sure. And all right, thank you Thomas. Like I said, well like Thomas said, I'm the Chief Product Officer at Instant. I'm going to sort of explain how we're using Hyperledger and all the associated tools and the specifications to extend our product at Instant and then going to be helped by my colleague Subatra on some of the more technical aspects. So welcome. First of all, just some context to describe what Instant does. And then from there show how we're using Hyperledger and the decentralized paradigm to extend our IDV and onboarding solution. So Instant was formed to solve a problem in the marketplace with digital onboarding. So currently we consider digital onboarding in the market to be broken. 40% or more of good customers are rejected due to vendor orchestration rules, compounding of false positives with all the underlying decision mechanisms. And this results in financial exclusion with thin file customers, new immigrants, anyone without a strong credit or financial institution history has difficulty in obtaining access to services. So at Instant, we've taken a different approach in the market to identity verification or IDV and KYC, which is the regulatory piece demanded by any financial institution. And instead of just producing an API which returns a score and then we're onboarding customers or rejecting them based on a score, we take a more holistic approach to the problem. We're treating it as a risk transfer problem where our system will de-risk any users that you're onboarding, it'll do fraud checks, it'll satisfy all the compliance requirements. But it'll do this within a framework of managing the risk in a way that allows you to grow your business and keep your exposure under control. Specifically, we offer, which is unique in the market, we offer a fraud loss liability indemnification of up to $100 million, which allows you to transfer that risk directly off your books. It helps financial institutions with credit applications to obtain credit to grow their business, et cetera. And it lowers the capital controls required. Another aspect of the service is we try to make it fully managed. So these IDV and KYC solutions involve a lot of different vendors. There's a lot of different moving parts. There's machine learning models, artificial intelligence, biometric instrumentation. And these are hard to manage and put together from a technical perspective as well as a commercial side managing all the vendors. So we sort of put our arms around this problem and turn it into a managed solution which uses a simple SDK to deploy. We're a single point of contact for you to manage this system instead of having to manage a whole stable of different vendors. Like I said, a big challenge to businesses implementing robust identity verification and KYC systems is the engineering burden, especially small institutions or even larger institutions, which their engineering teams are pulled in many directions. The burdens to taking on a big engineering project can be overwhelming and prevent them from using the best tools or techniques available at the time. So our solution is we support multiple tech stacks. We have SDKs that drop into web apps, a variety of web toolkits, native mobile and React Native as well for cross-platform integration on the mobile side. It's very much like Google Analytics. You just drop it into your app. If you're using out-the-box configurations, it's pretty much a no-code and with very little code, you can customize it to whatever your onboarding journey looks like. We consciously try not to force customers into any technology changes or any customer experience changes. Something else that's different is we charge for performance. So if we're covering the risk of fraud loss, you might ask, wouldn't we just reject everyone? So the healthy tension on the other side of this is we're only getting paid for customers that we onboard to your service. You're not paying for anyone that we deem a high risk and reject them. And this helps you to grow your business in a way and manage the fraud loss. So just to set the context for how we've leveraged hyperledger in our product, we basically, as it stands, our product instant accept is an IDV fraud protection and KYC solution. It usually serves a use case with customers, which is the predominant paradigm in the market day with a centralized identity management system. In this system, most of you will be familiar with this, although you might not know it by this name, but in this, the issue is of credentials or not the centralized databases are maintained of user information. So the services are sovereign in that they are the issues and the verifiers of these credentials. And what they're issuing you with when you sign up at a service is a username and password using which you can gain access to the system repeatedly. So this is not an identity. It's an identifier. It's a subtle difference in that an identifier is not portable. It doesn't mean anything to the bank down the street or the another e-commerce site. It's only meaningful within the context of the service, which is maintaining the centralized database of all their user information. Again, there are privacy limitations here. Users have limited capacity to control how their data is shared. They lack the ability to enforce the right to be forgotten. And this centralized database full of user information is a cybersecurity risk for the service provider itself. It forms a honeypot and cybersecurity insurance risks are rising as a result of this risk which companies are taking on. So that's sort of mostly the world as we know it today. And I'm sure anyone who's familiar with hyper ledger in the use cases they're supporting, there's a big push out there to move towards a decentralized identity management paradigm. So there's a big logo of Bitcoin on there. This is very often confused decentralized identity is very often confused with decentralized finance. So there are some commonalities in the underlying technologies and they're using distributed ledgers to share keys and to create an immutable shared reference of transactions on the database. But other than that, it's very different. And I'll describe with comparison to the description of the centralized system prior. In a decentralized case, the users are self sovereign, meaning they have very much more control over their own identity. The issuers and verifiers are disintermediated, meaning those issuing credentials are not necessarily and probably most often not the verifier. So this creates a landscape within which as long as issuers are subscribing to a certain governance framework can issue credentials and verifiers can verify the integrity of those credentials without having to contact the issuers just using the structure and the cryptographic protocols. The identity issuers will issue proper identity. So these are self describing the capture all of the information about a user and make certain attestations about the checks and balances that they've passed, age checks, KYC checks, etc. And these are portable because they're self describing a user can download these identities to a digital wallet or some sort of cryptographically protected store and they can go to other service providers. Those service providers, as I said, can verify independent of the issue that those are valid identities. And because the users have control over the their identities, they have more control over the privacy with their privacy. So they can delete credentials, they can expire credentials, they can win challenged for certain information can present just the amount of information that is required for service provider to onboard them. For instance, an age check, they can just prove that they are over 18 without having to give their name, address and phone number. And compared to the centralized case, this alleviates the cybersecurity risk, because users are maintaining their own identity in their own identity wallets which are protected biometrically and cryptographically. There's there's the potential for service providers to not have to maintain a big juicy database full of user information presenting a big cybersecurity target. Anyway, so there we presented the comparison in a sort of technology agnostic sense between centralized and decentralized identity management. And within this framework, why instant access which is it's the extension of our instant accept product that enables decentralized capabilities on top of our IDV and KYC solution. So what we're offering is using instant access, you can enable a decentralized identity deployment on top of what you have already. You can operate a hybrid centralized decentralized scheme as you transition users from one scheme to the other or you can maintain a hybrid scheme, given that some users are more likely to be early adopters than others. Another benefit of this, as I mentioned, with the decentralized paradigm, there's the capacity for identities to be portable. So KYC, anti money laundering regulations are largely prescriptive. They tell us exactly what checks have to be performed. Now today, these checks are performed over and over again, each time a customer onwards at a new financial institution or one that's financially regulated. They would go to Bank A, be subject to certain checks, they would go to Bank B to open up another type of account and be subject to the exact same checks. Under instant access, once they've, once instance has performed all the KYC checks and issued a verifiable credential, which the user then holds in a digital wallet, as long as the institutions all subscribe to the same governance framework and accept that instant is a compliant KYC vendor, they can be onboarded frictionlessly without any additional checks with a second institution can be confident that the checks have been performed at some point and are attested to that effect by instant. Like I said, using governance frameworks within which we standardize on level of assurance, wherein we describe exactly the checks and balances that are applied. This facilitates the transferability from one institution to another where they can actually, if they have some very sort of specific requirements around KYC or some specific risks that drive additional checks, they can, they can looking at the level of assurance specification determine whether the checks that have been applied match their requirements. And again, if you're not within a broad governance framework used by multiple services, you might ask, how do I leverage this portability? And you can do that just with simple password is logging on your own site, or if you have different product silos that currently use different onboarding mechanisms, you can leverage the, the verifiable credential in a digital wallet to allow seamless onboarding between these silos. And also, like I said, the password is login. So I'll hand over to my colleague, Subhatra, who'll dive into but more of the technical aspects of hyperledger and how instant is leveraging those to build instant access. Thanks, Justin. So I will share my screen. And I will talk about instant accept and the underlying technology framework. Hi, everyone. I'm Subhatra Das, the head of engineering at instant. The core decentralized technologies and framework under pending instant access are a result of a collaborative effort that created by a set of industry leading organization, service foundation and other consortiums throughout the last several years. And that resulted in a combination of identity framework, which is open, which is standard based, and which is based on distributed technologies like blockchain. And these standard organizations like W3C, hyperledger, decentralized identity foundations, they work collaboratively with each other to create these decentralized identity standards and protocols, which were missing in the traditional internet era. But these initiatives actually creating those building blocks, which are similar to what drives the basic internet in form of TCPIP protocol, HTTP specification and all other things that we know of today. So I will delve into a bit more about some of these underlying technologies. But I'll touch the surface because these technologies and standards are quite deep and vast, but to relate with instant access and focusing on how it works. On the top of this list is a distributed ledger technology, which is the common implementation is blockchain. And this by the characteristics of being programmable, distributable and immutable, it gives the characteristics that this technology or an underpinning data storage of these is not controlled by any central authority. Decentralized ID or DID as it popularly knows, on the other hand, provides a unique identifier to any actor who needs a decentralized identity in this system. Didcom protocol provides a very secure and peer connecting mechanism between two actors into this system. Verifiable credential on the other hand, act as a blueprint where in real world, we have our credentials like driver's license, passport, or any other. But it adds a digital layer that it is cryptographically very verifiable. And that way cut down the friction and effort in the verification process. Instant being identity assurance and KYC provider adds a level of assurance which is following this standard, which provides the credibility and assurance on the credential that instant provides as part of the instant access. And JSON LD schema is the manifestation, which is JSON linked data format, which represents the verifiable credential. Now I will talk a little bit more about decentralized ID. It follows this standard format, which is very similar to a URL, which we are all familiar with. It has a schema, and it has a DID method and then the third component is an identifier. But unlike the URL, the DID method can be different and close to a ledger implementation, which is similar here. And in this case, instant access uses the indie solve, which is tied up with the ledger implementation for decentralized identity provided by sovereign foundation. Next, I will talk about similar concept, which is around this did architecture. So did nothing but a unique identifier can actually discoverable and resolvable. Did points to a particular subject, and that subject can be any individual or an entity or abstract thing, or can be a IoT device. Did subject can be the did controller itself, or it can be different. In digit identity world, in most most of the cases, the controller and the subject are the same provides the uniqueness that the subject owns that identity. But it can be different in a sense that the subject is a minor or a pet. The controller is the owner of the pet or the parent or guardian of that minor. Did also can will be extended by a did URL, which provides additional information, whereas the did becomes discoverable. Did resolves to another impact that is which is called did document. And did document contains several other important aspect of the deed. For example, the document contain the controller who controls the deed. The document contains the verification methods defined. The document also can contain a service URL through which the discoverer can know how the did can be operate. And did is generally recorded in a blockchain or verifiable data registry. And when I say blockchain, blockchain is the most common manifestation of a verifiable data registry, but it doesn't need to be to move to talk about a bit more about verifiable credential. As I said, these are very similar to what we have in real world, a passport or a driving license, or even a library card, which can prove the identity of a person in within a particular use case. But unlike their counterpart in real world, the verifiable credential in the digital distributed world can be cryptographically verifiable. And that way it cuts down the friction and reduces the need of a centralized authority for the verification process. A verified credential has three components. First is the metadata. An example is who is the controller of the verifiable credential. Second part is the claims. Claims are the attributes of verifiable credential. And the attributes like for example, if it is a driver's license, the attributes can be the name of the license holder, the issuance date or expiry date of the license, or the date of birth of the license holder, and likewise. The third component of verifiable credential is the proof. And that is where it difference, differentiate from the physical credentials is that the proofs are embedded and digitally signed by the issuer of this credential and can be verified without any central authority cryptographically with machines. Verifiable presentation on the other hand is a manifestation representation of verifiable credential. Thus abstract the need of exposing all the attributes or claims within the verifiable credential if needed. Verifiable presentation can take different forms. It can represent a multiple verifiable credential. It can be tied down with a particular verifiable credential provided by an issuer. And verifiable current presentations by virtue of they can be abstract, they can be a subset of verifiable credential. And they can be orthogonal also in a sense that they can answer a binary question with yes or no without exposing the details of a claim sits on the verifiable credential that way increases more privacy and security of the verifiable credential and the credential holder. Now I will talk about how all these concepts works together. So in the ecosystem, the verifiable credential is actually owned by a holder who is act as a end user. In stand or organization like in stand who actually issues the credential are termed as issuer. Whereas instant customer or the businesses who uses this credential to verify these end users are called verifier. These three actors collaborate with each other to verify cryptographically without any friction and make these things seamless. And these are backed by verifiable data registry or blockchain. We initiate the process. The issuer like in stand need to write their deeds or identifiers as well as a schema or verifiable credential definition representing the verifiable credentials in the designated blockchain authorized by particular authority. Instant uses sovereign foundation for that and act as a stewarding there. And by virtue of that, the stewards runs different nodes in the blockchain and make it distributable so that there is no central authority with the blockchain principle. At the start of the process when a instant customer as a verifier sign up for instant access, they can integrate instant access with their system and ask the end users to download a instant compliant wallet into their mobile device. Once the holder or the end user install the instant compliant digital wallet into their mobile device, they can sign up with that verifier or instant customer. And once they are successfully weighted by instant as an issuer, instant access publishes verifiable credential. This credential is manifested by verifier in many different forms. It can be a QR code or it can be a link or it can be a deep link. And once the end user scan the QR code or click on the link, they can download the verifiable credential into their wallet. From that point onwards, anytime the verifier need to re verify that end user, the end user doesn't need to provide their login credential or their PII data again and again. They can just provide the verifiable presentation from the verifiable credential they hold into their wallet. So I will talk next about how all these things are possible, given that there is a huge amount of standard and technologies and protocols involved into this process. All these things are made possible by a set of tools and libraries provided by Hyperledger Foundation. And specifically for decentralized identity management, Hyperledger Foundation provides three frameworks and tools. Hyperledger Indi acts as a implementation of the decentralized ledger or blockchain, which is tailor made for identity management. And Hyperledger Ursa, on the other hand, creates a library which is provide all the cryptographic need by independent of all other layers focusing on their core purpose and provide a strong and as your implementation of the cryptographic methods. Hyperledger Aries, on the other hand, sits on top of Indi and Ursa provides a secure and private communication mechanism between the actors of the system. And now I will delve a little bit deeper into this stack. As you can see on the screen, Hyperledger Indi sits at the bottom of this stack and provides the ledger as well as the nodes and the resolver, which is the interaction mechanism between the Indi and the upper layers. Hyperledger Aries sits on top of that. And it provides the communication mechanism. Hyperledger Aries architecture provides a digital identity implementation where each actor whether they are verifier, whether they are issuer or whether they are holder into the system, they are represented by a identity agent. And these each agent can interact with each other, exchanging their deeds in a secure peer to peer protocol. Now, all these things implement the technology stack of the system. But the community while working on these over the years understood that technology is not the only important thing and needed here. We also need to be compliant with the governance framework and rules and regulation of the system, whether it's healthcare, whether it's KYC, or any other domain. That is why TrustoverIP Foundation, working with all other different foundation, created this trust framework, which has two parallel tracks. One is technology stack and parallel is governance stack. These has four layers. At the bottomist layer, we have the ledger and the related governance frameworks. The layer two constitutes of the DITCOM protocol. And the governance of that layer three, where the credential, the very favorable credentials get exchanged sits on top of that and uses the secure communication facilitated by DITCOM, as well as optionally by the ledger itself. Organizations like INSTANT operate on layer four and build focused business and frameworks focusing on a particular business domain, whether it's a healthcare, whether it's KYC identity assurance, or travel, hospitality, or any other sector, where it need to provide decentralized identity management. This creates a unique synergy between INSTANT and the industry standard players, where INSTANT provides identity assurance through its core platform, which is a critical precursor of any identity management. And now with the help of hyper ledger tools, INSTANT enables end user to own their identity and decrease the friction, thus provide ease of use and trust into the system. Now, how the customers can enable INSTANT access? It is quite easy. Customers who already signed up for the INSTANT core platform, INSTANT access can log into INSTANT dashboard and with one click, they can enable INSTANT access. They can then instruct the end users to download an INSTANT powered wallet. And it doesn't need to be INSTANT powered wallet. Any wallet which can be used, hyper ledger arrays as a framework underlying can be used in this format. Thus, this increase more trust into this system that INSTANT is not controlling this end to end framework. Once they download this, they can actually sign up through the normal process. And once they scan the QR code or click the button, they can download the verifiable credential, as you can see on the screen, and they can operate the credential from that point now. So I will hand over to Justine to demo how it works and conclude the talk. Thanks, everyone. Thanks, Subhattra. Sorry, I'll share my screen. And OK, so as Subhattra mentioned, there's quite a lot of complexity going on behind the scenes here to enable this decentralized identity protocols, tools, etc. And the INSTANT access solution is fully open standards compliant in keeping with our managed solution. We try to take that complexity away from you. And like Subhattra indicated, it's a simple turn it on in our dashboard and it's enabled for your users that you're onboarding or verifying on KYC. Just to see what does this look like to our customers? Here's Acme Bank. There's sort of a pretend bank who's using INSTANT access to do KYC checks and verify their users. They've built a phone app and they've turned on INSTANT on the back end. And we'll just show you what this looks like. The very first time a customer comes along and onwards with the system, there's a sort of bootstrapping phase where they'll have to enter some PI. Our application at this point is using PII, but even before users starts typing information, we're already collecting behavioral biometrics from the way that they're using the phone and the device. We're collecting device intelligence, so geolocation, we're detecting a behavior that looks like a bot. And we're also doing velocity checks. So we're looking for distributed attacks where there's multiple reuse of different components of the identity in a short space of time. So here's just some simple information. You don't see INSTANT at this point, but our toolkit is running in the back end, like I said, capturing all this information. It's submitted to our back end, which takes all of this information and holistically. Sorry, I'll just go back a sec there. So at this point, the users being verified by INSTANT and Acme Bank has onboarded them and provisioned an account. So at this point, the user has the option because of the INSTANT access was enabled to have the option to download to the digital wallet to verify the credential, which basically gives all the information that was provided by the user and all the checks and balances applied for the KYC, the IDV, fraud detection and writes that to the wallet. So here, the users just using, like Estie said, an INSTANT wallet in this case, but any compliant wallet will do. The user has the opportunity to verify the information that's going to be encrypted in that verifiable credential. And as you can see, there's an identifier which maps to a transaction within the INSTANT system. The user accepts that into his digital wallet. Okay, then you ask, well, what is what does what do you get to do with that digital certificate? So here, in this case, like I mentioned, if you are not part of a governance framework with partnerships that you can go down the road to another institution, here Acme Bank is just using it to enable password as login. So you can see when a user is prompted for a username and password, they have the option of just saying, let me present my verifiable credential that activates the wallet. Here, you can see to log in, we don't need a user's phone number and address. We just need the fact their email address, a specification of their level of assurance to which they were validated and the INSTANT reference identifier. They are being prompted to share this because they have complete control or sovereignty over their identity. The wallet will not present anything that they don't have explicit permission to present. And with that, the wallet agent talks to the verifier agent attached to the website and the user is logged in. So moving to the larger, the bigger picture, we're now with a digital wallet and a verifiable credential. The user wants to go and sign up at another institution, which is partnered with INSTANT and subscribes the same governance framework. So here's Apple Mart. This is a fictitious e-commerce vendor. We're going to show they've built a website, but we'll show how using QR codes, the digital wallet on the phone can interact with the website as well. So first step, the user wants to onboard at Apple Mart. So normally this would, as it was required to bootstrap the identity with Apple Mart, the user has the option of filling out all the PII, first name, last name, phone, whatever is required. Or alternatively, they can, using the QR code, they can present, they can link the digital wallet to the website and present. And again, they've been asked permission. The user has to give its permission to the wallet in order to present the certificate to the agent. One is shared. The user is onboarded immediately. And Apple Mart knows that the user has been validated, KYC checked, and has all the information that was encoded in the certificate. So there you go. It can be used for password login or within a governance framework can be used seamlessly to onboard users with a single click using the digital wallet. And again, like whether in instant, just to give you a glimpse into what's happening on the back end, whether you're using the decentralized paradigm or the centralized, when a user is verified by instance, just to give this is in our sandbox environment, just to give you a taste of what information is captured about that user and is used in decisioning the KYC checks, the fraud checks, the IDV checks. So we provide a full justification of why the user was accepted or rejected positive, negative indicators. We're totally transparent about the data sources, but we present a summary here that's sort of data source agnostic that's interpretable and human readable. But if you want to drill down, we'll show you the KYC checks, any lists that rematch all the correlations to support the pieces of identity fitting together properly. If we capture documents, they'll be here. You'll see an image of the front and back of the license, the selfie, any data read from the barcode and correlated with the OCR. Like I said, when the user is entering information on the website, even before they've submitted the API, we've already gathered device intelligence version, software versions, geolocation and running checks on bot probabilities. Similarly for biometrics, all in a frictionless manner, we're checking the user's behavior against baseline models for bot behavior for rat anomalies, user coaching, etc. Velocity checks, we're looking for reuse of phone numbers, IP addresses, first name, last name address. So if these are used rapidly across our broader network, it's usually a strong signal for a coordinated bot attack. We have models that partition and give us probability of different types of fraud. And then these are all combined together to give an aggregate decision, in this case, to accept the user and onboard them. So in a nutshell, the benefits of using instant fraud loss indemnification you get to ensure against fraud losses. You can frictionlessly onboard customers, customers that are onboarded. We have the KYC being portable and transferable across a partnership network within a governance framework. The implementation is all open standards. You're not being locked into a Google wallet or an Apple wallet. This is an open framework. As Subhattra mentioned, these are using open source and free tools. These are using open source and free ledgers. It's a managed service. There's a lot of complexity. It's not trivial, but we've tried to put it together in a way that's pretty much a click for you to turn on in your framework. And account monitoring. We have instant verify that when the users are onboarded, we form a baseline for their behavioral signatures. And then ongoing as that customer uses your services as they create new accounts as they make payments ad payees. We're constantly checking to make sure that their behavior matches their baseline and that the account hasn't been taken over by another actor. In terms of customers, this is we helped a leading retailer drive you $11 million of fraud losses to zero with our indemnification and allowed them to grow the business with up to $20 million in a fraud loss liability shift. So that's quite significant. Normally, if customers want to grow their business, they've got to lower the standards, open the funnel a bit. And that usually comes with risk with the indemnification piece. You can grow your business and have the indemnification as a backstop for fraud risk. So the road ahead. A lot of in line with what Subatra was mentioning to flesh out the governance frameworks. These are the rules, protocols and semantics of what does it mean? What does the credential mean? Who are the issuers and what are the checks that they're performing? The standardization of KYC level of assurance. So the financial action task force provides guidelines for anti money laundering KYC checks. But each jurisdiction will implement this in a subtly different way. So we're working on homogenizing that and creating compatibility rules for level of assurance. Digital services marketplace, like I said, if within a governance framework, if different service providers are subscribing to the same governance framework, it unlocks the partnership network with frictionless onboarding within that ecosystem. And again, continuing our partnership with the OSS community, specifically the Linux Foundation, the Hyperledger Foundation, which are key to us being able to unlock this this capability in our product. So if you want to add more customers with less friction and zero fraud losses in minutes, check out our website. We're more than happy to set you up with the demo. We have great documentation. We have a GitHub site with all of our SDKs for the more technically minded. We're, like I said, open in terms of nothing's a black box. We're just trying to manage the complexity for you. Thank you very much. Right. Thank you very much, Justin and Subatra. So now it's time to turn our, you know, question to the questions from our audience. So first of all, would anybody like to speak up and ask a question to Justin or Subatra? You can just use your raise your hand button. I did see some questions in the Q&A channel here, Thomas. Yeah, exactly. And they're just wanted to know if somebody's want to talk about it. Otherwise, we can just move to the Q&A box as well. Okay. Okay. So LG is asking what about privacy? If the credential is on a wallet in a public blockchain, anybody will be able to see it and know who's the owner. I can take that one, Subatra. Go ahead, Justin. The it's a bit of a misconception. The blockchain is and that's kind of why I drew the parallel between the the finance versus the identity use case in finance that every transaction is written like literally like a ledger with the decentralized identity. The keys, the dead keys are written to the ledger. So it's basically a mechanism for sharing public keys which can be used for signing. But the transactions and the verifiable credentials themselves are not stored on the blockchain. In fact, the guidance prescriptively from W3C VC specification is to not store any information which now or in the future could be at risk through cryptographic cracking. Yeah. And to add to what Justin said, this is this is the difference between the identity framework and decentralization from the cryptographic framework that drives the cryptocurrencies like Bitcoin is that Bitcoin transactions are actually written in the leisure, whereas identity transaction because they are associated with the PII is very consciously not stored in the leisure, but it is stored in the wallet. Right. That's great. Thank you. So we can just move on to the next ones. So how do you take a synthetic fraud is the question from Karthik? I'm synthetic fraud is, I mean, at a at a very the risk of some oversimplifying things, the the method of verifying identities involves a variety of data vendors, which we essentially going to ask the same same or similar questions to we get their responses and then we collapse that information back in on itself to see how well it agrees. So we as very simply would have to verifies or phone number using different methods. One would be an M and O registry, perhaps utilities, whatever is available in that jurisdiction. We could ask them the same question, what is the association or do you have an association between this name and this phone number or what intelligence do you have on this phone number and then checking for the strength of agreement between the answers. So with a synthetic identity is usually very poor agreement with the pieces of identity. And with synthetic, they actually usually don't resolve to any meaningful entity. Third party, which is sort of uses components of real identities will usually return data mapping to phone numbers, email addresses, but they won't agree very strongly. OK, thank you, Justin. And Anastasia is asking, does the solution screen for PEPs and OFACs? Yes, it does. So we use a service that manages watch lists, you know, with we're completely transparent with our customers what services we're using for that. But it checks, sanctions, probity, PEP, OFAC, I think there's a few we even do adverse media as well. So we do the full spectrum of watch list checks. That's great. And then we have a question from me, Novak and they're asking, can I revoke credential after I submitted to Wender and if yes, how? So, Bacca, do you want to tackle that one? Yeah, so this is built into the system, the process of revocation, you know, since when an issuer like instant actually first put their credentials into the laser, they can optionally go for a revocation registry. And the revocation registry is a service that built into instant site, but it is correlated with the laser. So whenever instant as the issuer need to revoke a credential, the consultation of an instant customers who act as a verifier, they can do that through that process. OK, thank you, Subatra. And we have another question. So is there a possibility to store or embed the keys or view them through other FinTech or other apps? Because one of the attendees is wondering, there seems to be a scaling challenge to have everybody download the instant. Justine, I can take that. OK, sure. You know, since that the core underpinning of decentralized identity ourselves, our identity or based on the principle on which the instant access is built upon is that the owner of the credential, which are end users should have control of their own identity and PNG information. And one way to store those information is the wallet and decentralized wallet in today's world differentiate from other wallet like you can get a general purpose wallet where you can store today's like your other credential information or credit card, a digital version of it, like Apple Wallet, Google Wallet, you can also have cryptographic wallet where you can store cryptographic information or Bitcoin and stuff like that. And there is convergence happening to consolidate all these, but all the convergence are happening to give empowering the end user to own their credential similar to in physical world once government issues a passport, the end users own their passport. Nobody else own that. So the philosophy is like that. OK, thank you. And Anastasia is also asking if there are any countries instant unable to do IDV. The data source we use are usually quite jurisdictionally specific right now. Our solutions focused on North America, Canada, the US and some of Western Europe. But the obviously on our roadmap is to extend that, but it's basically just applying the same sort of techniques with data sources which are rich and have high match rates in those jurisdictions. That's a great. And another question. So Minowak is asking, can I use my voice to create a verifiable credential? Currently, not with instant, but there's really no reason why you know, that's what the what I mentioned with the disintermediation of issuers versus verifiers. If a governance framework is defined with this within which voice is a recognized method for verifying a user within that framework, then there's no reason why you can't add that to a verifiable credential. As Patra mentioned, the schema that you attached to a verifiable credential is you can define your own schema. There's just a sort of a data structure protocol, but you can incorporate pretty much anything you want in there. Yeah, it's great. Well, the questions keep coming in. So that's great. We do have a couple of more minutes. So let me just continue from the beginning and then for those of you whose questions do not get answered, we will share the contacts later so you can ask us later on as well. So Renato is asking if you have used a sovereign network to support your solution and he's also wondering how mature is the solution now? Yeah, we use sovereign network, act as a steward in that network. And solution is maturing is this is as we mentioned that this is years of effort has happened to build the underground technology and standard and it is not just used by instant instant is using it for identity assurance. But there are several aspect or applicability of the same solution in many different domains, which has real world application. There are several use cases and working group in hyper ledger. If you guys are interested, you can go and check those out. And just to add like we built a solution around hyper ledger and sovereign provides a great sort of springboard for a solution like this, but we are ledger agnostic. Our solution can be configured to use any distributed ledger. We could, for instance, use the Ethereum chain or the blockchain. It's just a matter of writing the correct schema. Thank you, Justin. And that was one of the questions from early on from Saurau. So thank you also for answering this one. OK, and they were done is asking how does harvesting device info align with your regulatory compliance like GDPR? Do you want to do you want me to take that, Sobatra? Show us. Yeah, the toolkits we used to instrument the client, so be it mobile or web. They're usually, like, for instance, on the iPhone to obtain certain information like system level information, you would the iPhone SDK would pop up the dialogue to say you explicitly need user permission. We only rely on those just to reduce friction, because that's a big sort of value proposition of the solution. We only use information which is available without user permission on the device. So things like the IP address can be read from sort of the kind end point. But beyond that, it's just device information that's available without user consent, as controlled by Apple and Android, etc. Right, right. Great. Thank you very much, Justin and Sobatra. We do have some questions open, but unfortunately, we are on the top of the hour. So we will just wrap it up for now. And for those of you that couldn't get your questions answered, please reach out to us or to the instant team directly. So just to wrap it up, first of all, thank you so much to our panelists. Thank you, Justin and Sobatra. I think you did a really great job and very informative as you can see also in the comments that people really like it. And second of all, thank you to everybody of you who join us at this webinar, and we hope to see you again in our upcoming webinars. So before we conclude, I would like to invite you to join our Discord channel. There are many channels that you can explore and they're relating to our projects, such as Fabrik, Beisu, Aroha and so on. You can talk with our working groups, our regional chapters and much more than that. There's a lot of real-time interaction going on there and you're very welcome to join us. Now, we are hosting even more webinars and also workshops and you are welcome to go to our events page to see the upcoming webinars and register for them. One of the interesting workshops that I would like to invite you to is about building the how hyperledger technologies can be used to build central bank digital currencies or CBDCs. They will be the workshop will be conducted with cooperation with IBM and Bond of Homes, which they have their own CBDC trials in place. Thank you again, everybody for joining. Thank you very much to our panelists and thank you for everybody of you who joined us for our webinars and we hope to see you again soon. Thank you.