Good morning everybody, warm welcome for everyone in the room and for those that are watching online. I'm Katryna Dow and I have the privilege of introducing this panel presentation session on building a scheme. So one of the things that we know just in setting the scene is that as technologists we've spent a lot of time over the last decade looking at the evolution of identity access management, decentralised identity, verified credentials, issuing, verifying the full lifecycle.
And now we have some new challenges which is how do we set the rules, what's the governance and how do we commercialise this type of technology. So I'm delighted to be joined by Rintaro Okamoto from DNP who's going to share some of the really interesting work that DNP have been doing in Japan and through the Asia-Pacific region. Then Steve Pannifer from FEME who has deep experience in the problems of getting trust and governance across payments and identity. So he's going to talk to us about what are the building blocks in order to build that layer.
I'm also honoured to have Okimura-san who presented last year also in the cross-border working group looking at collaboration between a Japanese bank and Australian bank. So he's going to talk about some of the visionary things of actually putting this technology actually into market. And then we're privileged to have Emma-san from MUTB who is going to actually talk about some of the consortia work that he's been involved with bank to bank along with the Ministry of Finance in Japan of doing a technical POC to start to surface what the requirements will be for an ecosystem to operate.
So we're looking forward to some great questions at the end of the presentation and I'm delighted to start with Rintaro. Thank you.
Thank you, Katarina, and thank you for joining today. I'm Rintaro Okamoto from DNP. In my presentation, I will share with you the theme of this session and the challenges we've identified through our work on governance, technologies and commercialization of digital identity ecosystem.
To begin, I'd like to share a personal experience that will help you understand the use case we are trying to solve. My journey into digital ID began with this personal experience. In May 2021, my driver's license image data was leaked through a dating app. This incident created a genuine anxiety about how my personal information was being handled. I wondered, could banks share their verified data with apps without exposing my actual documents? This was precisely about using bank KYC data. This question became the foundation of my work in digital identity.
To address this pain point, I've engaged in various initiatives across the digital identity landscape. I've developed digital ID solutions and explore use cases with numerous partner companies. I'm especially pleased to acknowledge MAFG Banks as one of our strong partners in this journey, who will be joining me on the later. Through these activities, we've identified consistent challenges. Launching ecosystem requires stakeholder alignment across three critical dimensions, governance, technologies and commercial viability. I'd like to share some of the specific initiatives I've been working on.
One key initiative focuses on technical interoperability. We've established conformance testing site to verify capability between technical profiles, enabling connection with various Asian countries. This infrastructure allows different systems to communicate effectively while maintaining security standards, essential for any cross-border identity ecosystem.
Next, regarding commercial use case exploration, we've found cross-border working group with initiatives like Australian ConnectID. We've identified a use case that would connect KYC information from Australian banks to Japan, simplifying identity verification for Australian tourists. The Australian Embassy has participated in these document discussions, and we are working to identify and addressing key stakeholder challenges for commercialization. What distinguishes this work is our focus on real-world implementation to solve actual customer problems.
We are considering not just technical integration, but also business models and operational processes requiring for successful development. Finally, let me introduce our work on governance rulemaking. Governance includes digital certificate specification, legal rule, trust assurance level, and the role of various stakeholders. Within Japanese government's Trusted Web Initiatives, we've created a trust framework of data exchange between mutual aid applications. This was developed through discussion at IIW workshop and by exchanging opinions with experts.
Rebuilding a trust framework raised various important questions, such as who can be trusted as issuers and verifiers, and what roles governments should play. These considerations vary by use case. We successfully established version 1.0 of trust framework for mutual aid application with agreement across mutual application vendors. We have been coordinating technology, commercial use cases, and governance among stakeholders for each use case.
The major challenge is that three aspects are interconnected, and if we approach each use case by developing these elements from scratch, it will take a long time to realize our vision. Going forward, we need to adopt more efficient approach to building ecosystem in order to create various use cases across different industries. In today's following presentation, we will introduce two approaches to advancing ecosystem formation. One is a scheme development approach.
Steve will explain how to create schemes to accelerate consensus building among stakeholders across regulatory, commercial, and technical domains. Then, MUFG and MUTB will introduce to consortium approach as an initiative in financial sector in Japan.
In Japan, we are working on connecting digital certificate across multiple finance institutions. They will present more concrete example of ecosystem formation, including why banks are working in this area. While these initiatives are still in progress, they represent significant step towards solving the personal pain points I described at the beginning, realizing the use of KYC. We are moving closer to a world where digital identity are both secure and convenient.
Now, I will pass the microphone to Steve. Thank you for your attention.
Thank you, Rintaro. Yeah, so I'm Steve from a company called Feme, who are a provider of testing and certification solutions in the payments industry.
So, you may not have heard of them, but they're a pretty big company, about 1,000 people, with labs and software. Up until last year, I was managing director of a firm called Consult Hyperion that was acquired by Feme.
So, we're part of the Feme group, and the Consult Hyperion brand still exists. So, we have an advisory capability that kind of sits alongside the testing and services. Deep experience in payments.
So, we have a lot of experience in payments. But also, a lot of experience in digital identity as well.
So, I'm going to talk, as Katrina mentioned, about what a scheme is, why you need a scheme, and some of the building blocks of building a scheme. And then go on to think about the current nature of the industry, and how we can make the most of it. And some of the building blocks of building a scheme. And then go on to think about the current nature of the environment, and how we can move towards getting interoperability in the future.
So, three kind of opening questions. Why are schemes important? What we're talking about here are open ecosystems with multiple participants wanting to collaborate to enable people to do stuff with digital identity.
So, I might have a wallet. It could be from any number of providers. In that wallet could be credentials that have been issued from any number of issuers. And I want to be able to present that to, in any number of contexts, to any number of verifiers. This is the vision that we have. And we want to do that within context.
So, it could be within a sectoral context. It could be within a country. But ultimately, we want to be able to do that internationally, and kind of across many different digital interactions that we may have. And the way that you do that, or the only way that you can make that work, is there need to be rules in place. Rules in place that ensure that things are interoperable.
So, if I turn up with my wallet in a new context, it's going to work. And also, those rules need to create trust.
So, if I turn up in a new context, the other party needs to know that, okay, they can interoperate with my wallet, but they understand the basis under which that interoperability is going to occur. So, that's why we need schemes. Schemes help to facilitate that. Where can we learn?
Well, we can learn a lot from what's happened in the payments industry. We'll perhaps talk a little bit. I'll touch on it a little bit in my talk here, and then maybe we'll come back to it in the questions at the end about the payments industry. The payments industry, particularly the card payments industry, has been around for 60, 70 years. There are lots of things we can learn from the journey that they've been on. Our journey will be different, because the context that we're starting, the starting point's different. But there's a lot that we can learn from.
And then, the other thing that I wanted to touch on as a sort of an opening statement is just to say there's a difference between governance and operation. I'll expand on that in a second. And in particular, I wanted to say there's a difference between where centralization occurs and where decentralization occurs. There's a lot of talk in these kinds of events about decentralized identity, and often that's focused on the technical architecture.
So, looking at things like wallets that you put into the hands of individuals that can operate in a kind of portable way, in a sort of decentralized way. That doesn't necessarily mean that the governance is decentralized. The governance could be, but those are two separate things.
So, we're talking about decentralized architecture, but the governance may be done differently. So, what do we mean by a scheme?
So, here's a picture of some of the layers in a scheme. I'm going to start at the bottom and work to the top.
So, at the bottom, we have the people for whom which this scheme exists. I'm a normal person. I want to present some information about myself, a credential and a context with a merchant, a relying party. It could be another person. It's for us. It's for me, for the merchant, for the businesses that want to share data that the scheme exists. We want to get stuff done, and in order to do that, we have to have the services, the tools provided to us to enable that to happen.
So, we're the ones that benefit from the existence of the scheme. How do we do that?
Well, there will be what I'm referring to here as scheme members, organizations that provide services. So, as an individual, I might go to an organization and they'll give me a wallet. They're managing the wallet on my behalf, but it's my wallet that I'm using to do those transactions.
So, those scheme members, I'll expand some examples of scheme members in a second, those scheme members have to follow the rules. We need to make sure that the services they provide are delivered in a reliable, understood, trustworthy manner. And that's the way that we can ensure that when I turn up in a new context that things will actually work. Then we have what we might call a scheme operator.
So, within a scheme, there are probably some functions that need to be done centrally, or need to be coordinated, I should say. That could be some procedural things.
So, the process that you go through to onboard a member to say, yeah, we've done the conformance testing, we've done the audit, we understand that this organization is fit for purpose and they can be part of the scheme. That's a process thing. But then there also might be some infrastructure as well.
So, at the most basic level, there may be a trust list or a directory, something that the scheme members can refer to, to recognize when other organizations are members of that scheme and that they can interoperate with them. So, there's an operational element to the scheme. And then over and above that all, there's what we might refer to as the scheme owner. The scheme owner is the organization that actually defines the rules. And that separation between ownership and operation exists in the payment networks as well.
If you go to a Visa or Mastercard, for example, they have the scheme and they have the operation. In their context, the operation is a big switch because they're switching transactions between banks. But that distinction between defining the rules and then implementing and making sure the rules are followed is a very important distinction. The other thing to say is the scheme owner doesn't have to be a single organization. It could be a single organization. It could be a commercial entity. It could be a consortium. We heard about that as an example that Rintaro just mentioned.
It could be a public utility. There are different ways that these things can manifest themselves. And it isn't the case as well that you pick one and you stick with it. If you look at the history of the card networks, for example, a lot of them started out more as consortiums, particularly the big networks, and have become commercial entities later on. And there are numerous examples I could cite of organizations that have started in one place because they were getting things going. And then over time, the context changes or the business gets bigger. So they pivot and do something else.
But this is the basic structure, the basic layers, just to expand out the scheme. So this is the same diagram, but just expanded out the scheme member thing. So in the decentralized identity space, we're typically talking about issuers, wallet providers, and verifiers. There are other roles, scheme member roles, for different types of schemes.
So, for example, if you had an open banking-based scheme, then you may not have the wallet in the middle. You perhaps would have data providers and data consumers, depending on the terminology that you're using. So there are different ways that these can manifest themselves. But there will be schemes that provide different functions to enable people to do the stuff that they need to do. In other words, collect the credentials, the assured data, hold and control that somehow, and then present it in a particular context. So this is what we mean by a scheme.
The most important thing in the scheme is the rulebook. And what the rulebook does is it defines how the whole thing hangs together. So it will cover all manner of things. It will talk about the governance structure. Who are the organizations involved in running the scheme? What's the voting rights? How do decisions get made within the scheme? What's the process for bringing members into the scheme? The onboarding process, making sure that they comply with the rules, monitoring. What's the approach to privacy within the scheme? What happens if something goes wrong?
What protection is afforded to the users of the scheme? Everything that you can think about that needs to be there for an individual to be able to use something, for it to be interoperable and trustworthy, needs to be defined somehow in the scheme. And a lot of the conversations we have around interoperability tend to be very technical.
You know, I'm a technical person. I love to get into the weeds of what spec are we using, etc. But to get true interoperability, in other words, that vision where I can take my wallet with some credentials and I can use it anywhere, there needs to be more than just the technical interoperability. There's got to be an agreed commercial basis under which that's going to happen. The commercial basis could be that it's free. It could be that there's some fees that are due to be paid. Not specifying any particular approach, but the commercial framework needs to be there.
And there needs to be some regulatory rules that govern how the whole thing works. Now, the rule set doesn't have to be long, but it needs to be complete and precise. And what I've put on this slide here are some of the guiding principles that typically I think you'd need to follow in order to create that rule set. So from a regulatory point of view, you need to align with frameworks. We have lots of trust frameworks that are emerging in different places. Australia's got a trust framework. Europe's got a trust framework. Canada's got a trust framework. Those trust frameworks address...
Some of them are more focused on assurance. Some of them go a bit further. Very few of them go into commercials. But there needs to be alignment with those frameworks because those are the things that digital identity services are being built against. There's obviously got to be a regulatory alignment. So depending on the context in which the digital identity is going to be used, it needs to align with the relevant regulations. So if it's going to be used in an AML context, AML alignment, and other sectors will be similar. So that's regulatory.
On the commercial side of things, I think there's some important questions to ask. We need to make sure that the incentives, the commercials, the structures that are used to make the thing work commercially actually promote good outcomes. We've seen in a lot of the internet services, I'm not talking digital identity, but broader social media things, that the commercial structures often lead to undesirable outcomes. Services are free.
No, they're not free. You pay for them in other ways. And so we have to think very carefully about how we build the fee structures around those schemes to make sure that they do work fairly. For the participants, the members that are building stuff, there's got to be a commercially viable business for them. But for the end users, it needs to work for them as well. At the end of the day, this whole thing exists for people like you and I. And an important aspect of that is liability often gets kicked down the road. But it is an important thing to think about within the context of a scheme.
And then last, of course, there's all the technical stuff. I won't go through that in detail because I think we'll be very familiar with that. So that's the guiding principles that you would use to then formulate the rule set. And that gets you to the point that you have a scheme, a standalone scheme. It could be a scheme in a particular country, in a particular sector. So then the next important question is, what about if you want to join schemes together?
Because at the moment, we're in the situation where we're kind of in the identity space where the payments industry was decades ago, which was you had emerging schemes, but they didn't yet interoperate. There was islands of activity. The identity space is going to move a lot quicker. But the question is, how do you join those islands together? So I thought it'd be interesting just to look at a couple of ways this works in the payments industry. The first example is, I'm talking about point of sale transactions.
So when you go to a point of sale and you tap your Visa Amex Mastercard, you don't think about whether it's Visa Amex Mastercard. You don't have to make a choice. You just tap your card and it works. The reason it works is interoperability is assured or it's delivered at the end point. It's the terminal that works out whether it's a Visa Amex or Mastercard. And the level of coordination that needs to happen across the schemes to make that happen is tiny.
Basically, when you tap your card, that initial interaction between the card and the terminal just does enough so that the terminal can see your card there. It can inquire from your card what type of card it is, work out whichever brand it is, and then it goes into the specific processing for that card brand. And so what you end up with are parallel rails. So it gives the impression of full interoperability. But really you've got rails running in parallel with a little bit of interoperability at the end. But it kind of works in terms of building a system that works at scale.
So that's one approach. Another approach is the idea where you join schemes together. And you see this a bit more... So the top one is what you see mainly with global payment schemes. The bottom one is what you see more with domestic payment schemes where you have schemes in different countries and they kind of have bilateral relationships between themselves. So an example here would be... You've probably heard of the Discover payment network in the US.
The way that they get interoperability into other countries is they have bilateral arrangements with domestic schemes in other countries so that you can have a card that's issued with a Discover brand and you can turn up in India or somewhere and you can present it at a local domestic scheme transaction and the two fit together. And the way that they do that is they have to agree some minimum set of rules that they both understand and work with but what's happening in each of the schemes is kind of a black box. Everyone doesn't have to know everyone else.
So that's another way of approaching interoperability. So how would we get that inter-scheme interoperability in identity? Well I think there's three possible ways. There may be others but these are the three that I wanted to mention. So the first one is the idea of a scheme of schemes and there are organisations out there trying to do this. The idea that you have like a top-down approach where there's a scheme at the top. It sets a common set of rules and basically it kind of sits above all the schemes you're trying to join together. So that could work where you've got a clear coordinator.
Someone that clearly has the role where they need to coordinate amongst those different schemes. You could view the EIDAS initiative as a scheme of schemes because what the European Union, what the regulation does is it requires member states to issue wallets to their citizens. Each individual member state has that responsibility. Also from a certification point of view it requires member states to set up certification schemes which is obviously part of that overall governance picture that I talked about earlier.
And what the EU is doing is they're setting the basic rules that everyone aligns to. So I think it's a valid way to think about the EU in that way. Bilateral agreements. I think this is probably what we'll see emerging in the short term where there's no obvious coordinator. You've got schemes in different countries. There is no super country that sits above them all that can join them together. But there's a desire and there's business reasons why you want to join schemes together. So you come up with bilateral arrangements to make that work.
And then you could imagine that over time when you have a critical mass you would then perhaps pivot towards a different type of model. And then the other model is can you do it in a more decentralized way? So actually I've got a wallet and that wallet in effect becomes a participant in multiple different schemes. The analogy here would be the OEM pays, Apple pay, Google pay. So if you've got one of those on your phone it works in a Visa context or it works in a Mastercard or an Amex or Discover or whatever context.
And that's because they've gone through the process of in effect becoming a part of each of one of those schemes so you have a wallet and it appears to be interoperable with everything and it is but only because they've done the work from a bottom up way of doing that interoperability. So I think there are different ways it could pan out. That's where I'll stop.
We're going to hear now from MUFG and MUTV about the specific initiative that they're working on in Japan and then maybe at the end we can come back and have a discussion about what they're doing, where it will go next in terms of moving from the POC that they built to building a fully fledged scheme. Thank you very much.
Okay, hi everyone. My name is Omura from MUFG. MUFG is one of the major financial institutions in Japan and I belong to the corporate planning division. So I belong to planning. My work in MUFG is to plan the strategy for the firm. And so that being said, I would like to touch upon how I view the future prospects of the digital ID from a banking business perspective. So in the banking industry we are facing a need to really redefine our social role and the business portfolio itself and the strategy.
And within that, the ID or digital identity, I think is a very key component that will bring us to the next business model. And one thing that we see at this moment is that there is open banking and expansion of the open banking or integrating open data which is outside the financial sector and offering very personalized service. Maybe one of the pathway that could really leverage banks' creditability and the network. And I would like to just briefly touch upon the open banking sector in Japan. It has been open since 2018.
But we are showing there's a couple of hardest barriers for the market expansion. One thing is that the people in Japan they have a very high level of caution of having their personal information circulated. And another thing is that absent of the API platformers. So we don't have the infrastructure, a strong infrastructure to circulate the information itself. And of course we have the very burdened KYC process and that's so the use cases or the use cases or the market itself in the open banking sector in Japan is very limited at this moment.
So in this context, the introduction of digital ID or the verifiable credential, I believe there is a very good potentiality to of course dramatically reduce the cost and efforts of the identity verification. But also enhance the accessibility to the information of the digitalized financial services and pave a way for multi-bank, multi-service envisioned even beyond what we see in the current open banking by securing data interoperability and also the data trust. So we are actually co-working with ENP for last one, two years by now.
We are challenging to have very international collaborations especially in Asian Pacific region. And with that, I believe the digital ID or the verifiable credential has the potentiality to expand the bank's business portfolio or the new social role that we play in this world right now. So following this, we have conducted POC with the major Japanese banks to circulate the KYC information as a first step of utilizing the digital ID. So I would like to pass it on to my colleague, Imai-san, to introduce what we have done in the Japanese market. Thank you.
Thank you, Omuro-san. Hello, everyone. I'm Yasuyuki Mai from Mitsubishi Web Data Trust Banking. MUTV is one of MFG companies. I'm in charge of... Sorry. I'm in charge of new business development on the business side. At the office, the team next to mine has been working on digital asset business since around 2019. As we explore newer digital business opportunities, we see synergy in the IDBC.
Now, MUTV launched this consortium in Japan. It's a local initiative and nearly 50 companies are currently participating. I'd like to introduce our vision and what kind of POC has been conducted with Japanese FSA Fintech Hub since December last year. Our consortium aims to co-create business opportunities and achieving interoperability. As you know, the technical committees like W3C, OIDF, IETF, and also each government are working to standardize. So that's why we do not reinvest the wheel. Some meaning, so referred to standardization, in some use case.
Our vision is achieving interoperability between different platforms, so discussing governance and so on. In Japan, there have been many POCs by government subsidized and private sector in March here. But we are not the only one. But since it is a one-off POC, DID methods are different for each. So the potential of W3C has not yet been unlocked.
Now, we try to achieve that W3C can be used on any platform. I've seen the bank account opening use case pop up a few times over this event, and here it is again. Since both customers and banks are exhausted by repeated some verification step, so we thought, how if we could really be using identity data once it's been verified by any banks. The background is Japan is facing a declining birth rate and a huge number of people. Declining birth rate and aging population, which means our workforce is shrinking. Banks are finding it hard to hire and training people with AMS skill.
Since that's why we started thinking about reusing W3C issuing. This slide means our POC with Japanese FSA. FSA has a fintech POC hub to remove concerns and to help banks test new technology fit within existing laws. They are very helpful and even arranged for the National Policy Agency and the Digital Agency to join the POC. So we really appreciated it. The POC assumption here is that the user already has an account with Bank A, for example, think of Bank A as Mitsubishi Bank. Mitsubishi Bank issued KYC verified information as W3C.
And JPKI approved business operator issued W3C based on verifying with my number card. As a reminder, so KYC level is, so each bank is not the same. So each bank have to do risk-based approach. And this POC, I got advice from National Policy Agency. Verifier should not only look at the KYC data in W3C, should also understand Mitsubishi Bank KYC process, including what's asked and how frequently it's updated. The day before yesterday, Furukawa-san from National Policy Agency gave a detailed explanation about my number system. So I will skip the part of today.
When verifying identity with JPKI, there are two options. One is using the government's official my number application. And other one is going through on approval business operator's access services. For my number system, there are two options. Approval business operator's access services. For this POC, we choose a second option. My number MDOC will soon be issued and stored in iPhone's native wallet, which would remove, sorry, which would leave for private sector wallet vendor.
That's why we designed a scheme where W3C issued through approved business operator and stored in private sector wallet and VP with CDD information VCs. As we are designing, so, sorry. As we are designing this scheme referring EUDIAA, secure element is a meaning for the key management is the WSCD, not storing VCs.
So, if a private wallet use a tamper resistance module, like a secure element for key protection, storing VCs should not be an issue. This is a technical interoperability POC overall image.
So, issuer side is three banks joining and two business operators join. And the holder is three banks joining and the verifier, verifier are six banks and one mortgage company is joining.
Now, we are discussing and FSA, National Policy Agency and the Digital Agency to conclusion this POC. Maybe a couple of months, we are finality and to post our report. Thank you very much.
Thank you, Imai-san. So, we have opportunity for Q&A. I'm just going to throw a few things to the panel first and then we'll see if there are some questions either from the audience or online.
I think one of the important things that's very exciting as an observation for what Imai-san just shared is that here in Europe we take for granted the architecture of issuer, verifier and holder and we're starting to see this pattern emerge in jurisdictions around the world and Imai-san shared with me yesterday that what's very important is that the Ministry of Finance was involved in this POC and so the aim, if I'm correct, is to actually learn from that and which will then inform what may be the rules or the regulations might be. Actually, exactly.
That's the whole purpose of having the Ministry or the authority section involved in the POC. We don't want to build a new, wholly new structure or governance rule by ourselves from zero.
So, yes, you're right. So, Steve, you've had a lot of experience in looking at what happens when you have public and private sector come together. Do you want to comment a little bit of what might be that evolution of how these things sort of form and start to come together, particularly when you have government observing a technology outcome and learning from that?
Yeah, I mean, I think I'm going to give three examples here, Europe, UK and Canada, where they're taking that public-private sector collaboration in quite different ways. So, in Europe, it's being pushed from the public sector. There's regulation. It's being pushed down to governments and ultimately into the private sector as well, because the regulation demands that various sectors will adopt UD Wallets. I think the approach, the reason that's being taken is there's a bit of history. There was the previous EIDAS, and I think during COVID there were some identity-related challenges.
And there's obviously a much broader agenda in Europe around creating a digital economy, and the Commission wants to, the Commission and the European Union, want to push that forwards. They want to push that forwards aggressively, and I think that's the reason they're taking the approach that they are.
I mean, I think the timeframes are incredibly aggressive, but I think that's kind of deliberate. You know, I mean, I don't have any inside view about whether they believe that those timeframes are achievable. I wonder. But that's not the point. The point is they're really acting as a coordinator from the public sector.
In the UK, we have a slightly different approach. I won't touch on the confusion that's been caused in the last two or three months. That's a different topic. But the general approach is creating the rules to enable the private sector to then build out a digital identity ecosystem. So the way that they've done that is the government has held the pen in writing the framework, and when I say the framework, I mean the assurance rules. So they're not touching commercials. They're not even defining the shape of the ecosystem as they are in Europe.
But the idea is we'll create some kind of baseline that people can align themselves with, get some level of assurance, and then that can be linked to relevant sector regulations. So we had a couple of examples where the Home Office, a couple of years ago, said, well, if you want to do right-to-work checks, the framework used in a particular way is suitable for that. So it demonstrates that that kind of can work. And so it's a more hands-off approach in terms of how the ecosystem shakes out, but it's certainly government trying to play the role that they probably should play, which is regulate.
Now, obviously, there's this argument about should you regulate things into existence, or should you let innovation happen and then regulate afterwards? So I think there's still an element of trying to create the conditions to enable something to emerge. And then in Canada, you have a much more hands-off approach where digital identity has been a very political topic. And so there's organizations like the DIAC that are coordinating across public and private sector, but I think there's much less coordination in Canada. And consequently, I think things are moving more slowly.
So in answer to your question, there's really no single answer. Yeah. I think there are different ways it's panning out. Yeah. That's probably a great segue into you may have seen the session yesterday on the Asia-Pacific cross-border.
If not, I would encourage you to catch up on that catch-up time through the Kubingokor portal afterwards. But Rintaro, I wonder if you could speak a little bit about the fact that DMP has been foundational in creating the Asia-Pacific Digital Identity Consortium. And following on from Steve's comments, you're not waiting. You're actually building and addressing these issues.
Thank you, Katrina. We are now creating Asia-Pacific Consortium, and we are now looking for a real use case. So there are many stakeholders in this digital identity ecosystem. So it is very difficult for all stakeholders. But we are focusing on a real use case because the pain point is very important. So a real pain point is connected with a real use case. So this is the core idea we are focusing on now.
That's probably a great segue into seeing if there are any questions from the audience, because as Steve said, in any scheme, it's the user, it's you and I trying to do something maybe with our hospital or our employer or in the public sector or with our bank that is the purpose for these ecosystems to form. So Osman, do we have any online questions or questions from the audience? We can maybe start with our audience here first. Any questions? So the question is, is there a general framework for assessing partner IIM maturity? For...
I repeat again, is there a general framework for assessing partner IIM maturity? Okay.
Steve, do you want to... We can maybe... Because I think when we think of IIM, we often think of the enterprise as opposed to what's happening with decentralised identity where many of those rules are broadening and it's really more of an issue of interoperability. I'm not going to answer the question exactly, but I'll give an answer that's hopefully helpful. So we've been talking here, as Katrina said, about open ecosystems and who are the participants in those ecosystems?
Well, it will be enterprises, the members, the issuers, the wallet providers, the verifiers, and particularly on the verification side, sometimes we refer to them as relying parties, are enterprises and the connection point into those enterprises may well be the IIM platform. That's the thing that you connect to. And so there will be rules, standards, that are imposed or become relevant to the IIM providers because in order to participate in a framework, they need to make sure that they're lined up with that. The specific thing about is there best practice around IIM by itself?
I mean, that's not really the question that we're addressing today, but I think that's a good question too. I mean, there is nothing else than this question.
I mean, the person is anonymous. We don't know where they are.
Well, ping me on LinkedIn. We can have a chat. I think maybe a good follow-on from that question is one of the points that Rintaro spoke about.
In starting to establish this Asia-Pacific consortia, one of the first things that DMP did was investing, developing a conformance testing ability so that each member could bring their own wallet, but the first thing was technical interoperability, and that was one of the really critical things from Emerson's presentation is you had banks that may have different views about how they were going to go about their internal processes, but the first thing they needed to be able to prove is that bank-to-bank there was this technical interoperability.
So I think not to trivialise the technology, but often the technical interoperability is the fastest. It's the easiest to describe, particularly if we're using standards. So here's the profile. Here are the standards we're using. This is what we expect. We test that interoperability, and it's the first great step to being able to say, okay, we have different providers that are providing either an issuing, a verifying, or a holder service for the rules that we want to operate under, and then how do we make money? How do we make this commercial? Any other questions from the audience?
It is the Friday morning of EAC, isn't it? It's kind of inevitable, isn't it? We just have the opportunity. We have some experts that are deep in the weeds of trying to work out sort of those layers of complexity that come after the technical interoperability.
Maybe, Steve, if I throw back to you, we were talking before the session, and you mentioned that many of the payment schemes started really before the Internet, and so we've had 30, 40, 50, 60 years. Well, I looked it up. So AmeriCard, which was the pre-runner to Visa, was started in 1958. Okay. So I think it would be a disaster if we said to the audience right now getting an ecosystem, a global ecosystem, was going to take 60 years. So maybe you want to talk about some of the advantages that we have to go much faster because of the rails.
I guess the first thing to say is we refer to them as payment networks because there was no network. I mean, there was no technical network. There was no commercial network either. So they were really starting completely from scratch, and those early payment schemes were very narrow in terms of their scope.
Now, what happened was over decades, they, you know, okay, AmeriCard was the first one. Other ones started to emerge following the pattern, and they were all viable businesses doing their own right.
But then, of course, as things progressed, the scale increased, and we were not living in a digital world at all then. It was a very different environment.
You know, when I say there was no network, I mean, they had to design, build the terminals, plumb them in with a phone line or whatever. I mean, there was nothing, right? So that's not the environment that we're in now. We all have technology.
Now, you've got the technology to be there to be either the issuer, the wallet provider, or the relying party. You could do that all with the technology that we have in our hands, right?
And so, and everything's connected to everything else. So there's the building of the relationships, the building of the governance, that still needs to happen, but we're starting from a very different place. And I think also, as I kind of said earlier, it's not the case that you, well, what you shouldn't do, and it's not the case that we are doing this, you shouldn't sit down and go, well, let's design the perfect solution, and we'll figure it all out, and then we'll do it, because you will spend a long time getting there.
But actually, there are solving local use cases, doing bilateral things between Japan and Australia, you mentioned earlier, great example where you can get something real working now, and then it will evolve the organizations that are involved, the responsibilities will change, but there's still important pain points to solve right now, we can solve them now, make a difference, and do it in a way that's commercial, knowing that, you know, that's not the end of the story.
I think that's probably, there's a great example that each of us have collaborated with, and that is ConnectID down in Australia.
So ConnectID, actually, came out of FPOS, which is now Australian Payments Plus, but their hypothesis was that it was a lot of disintermediation happening in the payment sector, was becoming more and more difficult to compete with new services, but that rails and those infrastructure was already in place, and so their hypothesis, back in 2020, was that could we understand, understanding how to operate a scheme and payments, could we evolve that, actually, into an identity network?
And so, ConnectID launched a few years ago, and I have to say, the banks and the major retailers were the key consortia members, so I think we see things again, like open banking or open data, unlocking that, and then, as we showcased last year, there is, ConnectID, then, is acting as that connector between the work that DMP has been doing with MUFG to see what is it that we could do to extend, what rules have to change for us to be able to do this cross-border, which is much, much more complex.
However, there is an existing set of rules to be able to start comparing and saying, okay, we can agree, and I think, I don't know if Nick is in the room, but I'll probably get this wrong, but I love the way he says adapt, or there is one other A, which basically means you can immediately say, I agree to that rule, or, actually, I need to impose something or we'll need to adapt. And so part of the scheme to scheme is enabled by the fact you have sort of a blueprint to start out on. I've not heard of these three A's. I must learn them off by heart, but they're really, yeah, they're excellent.
And I think, Rintaro, that's really what you're doing with APDI, yes, setting the rules and then looking at these different parts of the world So, yeah, it is important to, for us, monetization. So, yeah, people who pay for is solving problems. So we're focusing on creating real use cases to solve real pain points. So this is our approach. Fantastic. So I think we have a minute on the countdown, which unless there's any other questions, it means that we can wrap up and people can get to the next session or stay in the room for the next session.
But would you please join with me in thanking our panel? And one thing I would like to say is that our Japanese, it's so fantastic to have our Japanese participants, and this is either the first or second time they've presented to an international panel in Japan last year, and it was atrocious. The audience were very forgiving, so I just think it's also wonderful that we are able to bring people from the Asia-Pacific and thank you very much.
