Architecting DLT Financial Infrastructures with SWIAT-CTO Ivica Aračić

Hello and welcome to another episode of BFRR, our Bitcoin Fiat and Rock 'n' Roll podcast that explores the intersection of traditional finance, digital assets and digital currencies and helps you understand how digital money and assets will evolve in the future. I am co-host Michael Blaschke and today we dive into the architecture of DLT-based financial market infrastructures. We've covered countless DLT pilots and experiments over the years, but today we're going beyond the headlines, beyond the pilots, beyond the experiments. We're talking about the actual architecture, the foundational blueprint of how DLT-based financial systems need to be built to action work at scale with real interoperability, proper governance and genuine market adoption globally. Joining me today is Iwica Alacic, Chief Technology Officer at SWEAD. As a CTO, he is the perfect guest to adopt an architecture perspective or lens or vantage point today. Iwica, you've been with SWEAD since its founding in February 2022, but your DLT journey in traditional finance started much earlier, you spent a decade at Dekarbank as an IT architect where you were already working on blockchain initiatives back in 2016, quite early for a traditional finance institution. With over 20 years in software engineering, a master's in computer science from Darmstadt and experience spanning everything from programming, language design to enterprise application integration you've witnessed, the evolution from theoretical DLT concepts to real production systems, welcome to Bitcoin, Fiat and Rock 'n Roll. Thank you very much, Michael, for the invitation, so I'm very happy to be here. Iwica, looking back at those early blockchain initiatives, for example at Dekarbank in 2016 versus what you're building at SWEAD today, what's fundamentally changed in how we approach DLT infrastructure for financial markets today in 2025? That's an interesting entry question. Well, the main difference, I would say, is that time, and this is not specific for Dekarbank, but I guess it's specific for the whole market, it was the phase where it started with how we bring things from zero to one, which is very typical for, let's say, innovative environments. So you have, let's say, some sort of technology that starts with a promise, and typically it is overhyped, and then you're starting from scratch like looking how to implement, how to integrate, how to leverage this technology and to bring benefits for the business. And so it is the question then how you move from zero to one. And then, of course, you make a lot of mistakes here because there are no manuals, no procedures like that you can follow. Of course, you can build on top of your experience, but there are a lot of things that you need to find out. And there are also a lot of dead ends which you meet and then need to turn around, go back and retry the other way around, and now being more specific like for DLT technology. So, I mean, you first need to see how use cases map on this new technology. You need to understand, you need to educate people in your company, you need to make some decisions on which technology to use. I remember that time on the table, it was like Ethereum, like R3 Corda, like Hyperledger Fabric, and then you need to decide what is the best technology to pick, will it survive the next years, will it survive the next five years, next 10 years. And then you come to conclusion, okay, you actually cannot decide that, so you start with something and things will develop and stay flexible. And the other things, especially with DLT is how do you manage the governance, because you have some sort of shared infrastructure and you start with a use case typically. You start with a set of people that meet to do something within this use case, but then a lot of questions also need to be answered in the periphery of that, like you have a shared infrastructure and how do you govern this, how do you manage this. So there are a lot of things and most people that are listening here, I guess they made the experience by themselves. And now the difference to today after 10 years, or as we started with SWIAT, so the initial idea of founding SWIAT was by saying, let's move from one to many now. So we have experimented, we tried things out, so we know how to go from zero to one. For the most relevant things. And so now let's look how to move from one to many, how to do we scale the use case. That's basically the mission of SWIAT to provide everything needed for the regulated environment, for the regulated institutions, for the regulated financial industry to scale digital asset use cases. And it starts with the infrastructure, but it also continues with let's say applications and tokenization and settlement engines and different services which make the access to this infrastructure easier. So that's the main difference. And what did not change, the fun. So the fun is, I would say the same. So it was fun as we started, and it is still fun today, different kind of fun, but still fun. Yeah, so you mentioned many reasons why I definitely wanted to have you as a guest today. Number one is, you worked in the space, particularly in the TREDFY space from the outset of the adoption of DAT, as I explained in your introduction, then second, you're a CTO and therefore just exactly the right person discussing architecture. And third, you have fun. So it's so important to have guests that really enjoy that work. That's in particular characteristics of professionals in the DAT space. They really enjoy this work because it's an emerging technology, a frontier technology, and that's beyond the technological intricacies and beyond the impact it potentially has, at least on finance. The fun that the professionals have in that space is something I really appreciate. So for those three reasons, I really wanted to have you here. And yeah, we opt for adopting an architecture perspective today on DAT-based financial market infrastructure. And the obvious question all now have is, why adopting this architecture lens? And why now? Why didn't we do so one year before? Why shouldn't we only do so in potentially one year? When I thought about the question, I've observed that we've seen countless DAT pilots, proof of concepts and sandbox experiments over the past five to seven years, and yet we're still largely in a fragmented landscape in the DAT industry. So why do we need to fundamentally shift how we talk about DAT infrastructure now? Why is it the right time to adopt this architecture lens or have this architecture conversation? Well, I would say it was always important to talk about this, about the architecture and because it's some sort of communication, building a common vocabulary and also making it easier to explain things. Because if you have the vocabulary, then you do not need to explain for days what you mean. You just tell one word, and if people are aligned, then you transport, let's say, strong or complex ideas with single word. So for the last 10 years, we have some sort of divergence, so we experimented with a lot of things. When I say we, I mean the whole market, so not only SWIAT, we experimented with a lot of things. We created a lot of, let's say, islands with a lot of interesting things. And this is typical, let's say, for the innovation phase. And even in this innovation phase, I think we also discussed about terminology and architectures, and we learned a lot of along the way. And now I think the market is about to make the curve to convergence and consolidation. So after 10 years of experimenting, I think everyone now kind of realizes it works. It works, and everyone kind of realizes we need to consolidate in order to leverage all these, let's say, promised benefits from the DLT technology. And I think everybody has the feeling, if we keep it like it is, it was good enough for innovation. It was good enough for pilots. It was good enough to come from zero to one, but if we keep it like this, then we do not have something which is better than status quo, so we just created a lot of friction between these, let's say, different islands that we have. And now we need to start to consolidate, and I think my impression from the last CyBus, it was two weeks ago, right? My impression was that the market is making the curve now toward convergence and toward consolidation. And as I said, talking about architecture, so it was always important, but I think now it becomes even more important, it should be emphasized more in order to create even a better shared vocabulary on what we have on a table and to make it easier to consolidate. Yeah, I agree with you that we now need a more structured conversation about both the 2B of our DLT-based global financial market, but also about the SES, landscape on a technological level. So with this convergence and consolidation happening, we need a more structured conversation. And for this, a shared target architecture and a shared vocabulary would be a powerful means to converge, to consolidate, and to develop a global shared understanding of what such A2B architecture could look like. Ibiza, you just outlined that you observe such consolidation and convergence. Can you maybe give one or two examples why you think so, where you observe this? Is it panel conversations? Is it increasing integration via standards? Why do you think this convergence and consolidation is increasingly happening now? If you look at the, let's say, news landscape, you hear more and more about, let's say, banks coming together and doing things together. And we also kind of contributing to this with Regulated Layer 1 to provide a network for European financial industry that would be neutral, would be open, compliance optimized, and also not designed for profit extraction, but managed as a shared utility for the benefits of its members. And if you look at Cyberspect and also SWIFT has announced that they will be doing SWIFT ledger, which is also a strong push towards consolidation, because someone like SWIFT, it has, let's say, the size and the gravitas to attract a lot of players. And consolidation is also happening at different levels. So you can consolidate regulation, can consolidate governance, you can consolidate technology. And also the SWIFT announcement is also a very positive thing in regard to consolidating technology itself, because they endorsed through the announcement Ethereum as technology, which I think is a good thing, because with technology, there are different flavors, but in the end, none of them is like by many orders of magnitude better than the other. So you could kind of cover, let's say, different use cases with different technologies. And the more important thing is to look what is the ecosystem around the technology. And so from my perspective, it was a good thing that Ethereum is kind of being endorsed in that regard. That's also, in the other reasons, you're also building on top of Ethereum. In this regard, so the market starts to consolidate slowly. And I think everyone kind of experimented enough and is realizing that they need to come to larger networks to leverage all the benefits. Yeah, really, like your idea of zero to one and one to many and will push for shifting the Modus operandi, the mode of working from zero to one. So shifting away from zero to one towards one to many. Because the market maturity requires this move from experimentation to implementation now. And there are regulatory clarity is emerging both in Europe and the US. And we need to avoid creating ever more new silos with new technology. And I think the industry is ready for consolidation, but still lacks this common framework, this common framework, without which you cannot build interoperable systems without a shared language. You need that vocabulary that enables coordination globally. You need an architecture that serves then as a communication tool between different stakeholders and standards that work or standards wouldn't work without definitional clarity. So I really like your push both for moving towards one to many and for a shared target architecture as a communication device without which every institution would build incompatible systems. I also have to say at this point, it will be difficult to consolidate everything to one single point. So I think this is impossible. So from this perspective, there will never be some sort of, let's say, silver bullet which is kind of giving a blueprint for covering everything. Exactly. So that will not be possible. But still, even if we have it like in, let's say, very simple form that the parts that we talk about that we can point with a finger to the same thing, let's say, some sort of a model or a layer, so that would already be beneficial. What we also observed, for instance, in our discussions within the Regulated Layer 1 initiative. So it starts already like with how do I differentiate between a blockchain network, the naked blockchain network, which is basically some sort of execution model for programs, how do I differentiate that from assets that are implemented on it or that are issued on it. And a lot of people mix these things. And this is just a small example on where, let's say, a common vocabulary helps and where it helps to talk about these things. All right. So we've touched a little bit on why adopting such an architectural lens is of value and why we should do right now. Most likely, many of you ask yourselves now, well, what is architecture actually? How should we conceptualize it to actually operationalize it to get work with it? So before we dive into where we actually are and where we need to go as a community architecture, let's establish a common framework. And for this, the IMF published a working paper in 2024 introducing the ASAP or ASAP model, which stands for Access, Service, Asset, and Platform. This is becoming, to me, an important reference point for thinking about digital asset infrastructure. It's a four-layer conceptual model for organizing functions in digital asset platforms. Also in digital asset infrastructure, it's similar to how TCP/IP layered model enabled the internet or interoperability in the internet. And each layer of the ASAP model has a distinct purpose and governance, and it has understand the separation of concerns in DLT systems. I will briefly define these four layers, and it will serve super useful in further discussing how as is and to be architectures ought to look like in the financial market infrastructure. So going through this four layers bottom to top, first there is the platform layer. This is the foundational infrastructure level. So this is about runtime capabilities, execution engines, storage, ledger, communication between nodes, consensus mechanisms, identification, authentication, authorization. Basically the "operating system" of the DLT infrastructure, most technically sophisticated, but also most diverse across implementations. Then second there is the asset layer. This is where tokenization happens. So it's the functions that define assets. It's core functions like state representation, issuance, transfer, redemption, access control, and the separation from the platform layer is key because the innovation is the tokenization. So it enables independent governance of assets from the platform operators. The same platform can host multiple independently governed assets. Third there is the service layer. This is where things get interesting for financial markets. It's about the functions that manipulate or use assets. Here I'm really thinking of payments, foreign exchange, lending, collateralization. So where most financial innovation happens and fourth, ultimately there is an access layer, the user facing layer. This layer is about how participants interact with underlying layers. Here I'm thinking of wallets, APIs, portals, applications, the presentation and formatting, credential management, data exchange. So where user experience really happens. So Ibiza, I hope you're satisfied with my explanation of the model, if not shoot and revise. Absolutely, all correct. No additions to it, but it's also important to emphasize it is one of, let's say, many models that are possible. What I like about this model is it is easy to understand. It is easy to understand. So it is composed of these four layers and it helps already a lot to sort things in. And one also, let's say, things where we always need to be cautious is no matter which, let's say model you choose, there are always like some anglers which are not covering all edge cases. I would say this model is good enough for discussion. Lovely. With that, we've established why the architecture vantage point is precious. We've briefly introduced this ASAP model to, at least for this episode, to find what we actually mean when talking about architecture and with that, let's shoot and dive into what we as a global community have achieved so far. So let's map today's reality of DLT-based financial market infrastructures to the model we just introduced. So now that we have this framework, let's use it to map where, at least in Europe, we actually stand today. Let's go through each layer and assess what we've genuinely achieved versus what's still aspiration. Let's start again on the bottom, the platform layer that's current state. So yeah, what do you think? Have we actually achieved at the platform layer, at least in European financial markets today? Yeah, I would start with positive things and then I think about gaps, we will talk then following this. Yeah, so on the platform layer. So what we have achieved is, and in my view that I'm presenting here is very much straight if I apologize for that, so it's not globally like including all, let's say, also cryptocurrencies and things. I'm talking from threadfile perspective, which means supporting assets that are regulated and that banks can take into their books easily. And talking about platform layers, so the good news is technology is working, and many thanks to public permission setting because it is huge, let's say, innovation jungle that we have there, and then we can get a lot of inspiration how things can work or should work. And we can really, let's say, take a lot out of this pool and tailor that for threadfile environment. So especially emphasizing here Ethereum, from my perspective. And so this layer works, and there is also a lot of confidence built up that it is not only like just working for one day, but it will also continue to work with coming years based on, let's say, the confidence that has been built up over decade plus. And so that's about the platform layer. And about the asset layer, so it would be the next one, building on top of it. In financial industry, everything revolves around assets. So this is, let's say, the reason why we are building actually platforms in order to manage assets in some way. And if we're talking about assets, then the first thing is how do I issue these? How do I bring them to life? How they are created or minted or issued, so depending on which terminology you use. And the next thing is how do I change the ownership over these assets? And now we have multiple perspectives. So one perspective is technological perspective. So you need some sort of a software, typically called tokenization engine software, which is able to create assets on blockchain. And the other perspective is the regulatory perspective. So you also need the corresponding regulation in order to bring these assets and to claim the same, let's say, financial instrument properties that you're eventually used from a Tread Fire environment. For instance, if you issue a bond, so a bond on a paper and a bond on blockchain should be basically the same things. And if you think back some years ago, so this was not that easy. I mean, we had things like registered bonds, there were very yearly experiments on it, but for instance, very bonds. So it was first possible with the introduction of ABPG, so Electronic Security Act, for instance in Germany. And so the good news here is that as well, technology and as well, regulation have significantly progressed recently or in the last years. And we are able to issue and to manage ownership of assets. And we are also able to issue not only like cryptocurrencies or tokens, but also regulated instruments that Tread Fire is used from the daily business like bonds, for instance, or like fund shares. And also important to mention here, when we talk about tokenization engines, so the current state of the art is you have basically two steps. So the first step is to describe an instrument. So you need to say which properties this instrument has from the financial perspective. And the second thing is that you need to open some sort of a registry or the other synonym for that is token, to open some sort of, let's say, bookkeeping for this instrument in form of a token or in form of a registry, depending on which terminology here again you're using. And we have different formats here. And yeah, well, the good news is formats exist to run this software and to open these registries and bookkeeping, but it's still in a very fragmented state where, let's say, no dominant formats have been involved, so to say, every time when somebody comes in and says I have a standard, then you can add plus one to the existing standards. And then in the end, you have, instead of 15, you have 16 standards, which is of course not the goal of this thing. But at least at investor side, a standard has emerged, which is called in Ethereum World ESC 20, which is covering the investor side. And I think standardization on investor side is also the most important thing to cover because typically on an issuer and the registrar side, you typically have one entity which is handling everything, but on investor side, the hands can change very quickly. And consolidation of the interface is very important. I think for this reason, so ESC 20 as a standard, very popular in the Ethereum world to cover the investor side. I have to say, what is my balance and how do I transfer things. And now going to one layer higher, so to the service layer, then we come to things like secondary market, trading, and we have two more complex, let's say, delivery protocols because once you have a token, you can say, okay, I have a token, I have a bookkeeping for it, I have some beneficial owner, now I can transfer to someone else. But the reality in the financial industry is much more complex than that. You need much more, let's say, complex protocols. You need something like delivery versus delivery, things happening in the same transaction or delivery versus payment if a payment leg is involved in this regard. And for this, you need 10 additional services also to manage these deliveries. To say, for instance, I'm giving a collateral for HQLA instrument, or I'm issuing this instrument and I want to get paid in central bank money. And as soon as assets are being on the same ledger, so this is of course easier, but this is also, again, not a typical case because assets are kind of scattered across different ledgers, be decentralized, be centralized. For instance, if we look at central bank money, the central bank money reserves are sitting in RTGS, which is also some sort of a ledger, managed centrally. And the digital assets are sitting on DLT, and now on the service layer, you have the challenge also to do something which is called cross ledger delivery versus payment. You need to be able to synchronize these things. And a few years ago, so it was like dreaming how to do it, with central bank money especially. But now we have concrete plans to get it implemented for Euro within the Pontus track, so during the next year, which is a very positive news to get all features complete in regard to settlement. And we also had last year a very successful exploratory phase from Euro system, so where it was possible also to link movements on DLT with the bit payment in central bank money. And we also participated in these, and let's say one prominent example of this is the Siemens Pond from the last year, 300 million, that has been settled delivery versus payment. So delivery owns via blockchain versus payment with central bank money. But I want to say here, so having the payment leg for more complex delivery protocols on this service layer is a very important thing, and we are about to complete it and have it in production very soon through Pontus track, at least in Europe. And the other thing is to have secondary markets. So this is currently we are issuing things, but secondary market is still in experimentation phase and I think with the pilot regime, so this will improve so that we also have the secondary market covered on the service layer. And the last bit that we need to meet, but I think we will not have very soon is eligibility of the assets. So in the beginning, I said a bond should be a bond. So independently of if it is on DLT or not, but currently it thinks on DLT are second class citizens, especially from the perspective of eligibility. For instance, if you go to central bank, then you cannot kind of get liquidity, give this as collateral and get liquidity for it because it is not included in eligibility framework. And with eligibility, you're still on the service layers current state. Yeah, that would be, yeah, exactly. That would be part of the service layer. Exactly. Yeah. So the service is like deliver me a collateral and I give you liquidity in the form of central bank. Yes. And looking at the access layer, well, the access layer is something which follows the services and assets that are available. And especially in an area of phase, people do not want to invest a lot of resources to install all these things on site on their own. So they want to kind of buy, so let's say easy access services to get onto the platform and to get into the assets and then decide eventually later to do own deployments and scale deployments on their own premise. So from perspective of this layer, I think we are pretty well covered in the regard, but it follows basically asset and service and platform layer that saw all these things that are happening happening below. That would be like status core summarized map on onto these architectural layers. David, thank you for your comprehensive and honest assessment across all layers, acknowledging both progress and gaps. I also like your disclaimer or context specification that we are talking predominantly about the European perspective here and predominantly about TREDFI. So this is by no means a complete coverage and tailing DFI and CFI, but this is really the target architecture of TREDFI when it comes to DLT. And I carefully listened, of course, and to me, some aspects stood out on the platform layer. I'm impressed that multiple DLT infrastructures are deployed, I'm thinking of quarter, hyperledger, private Ethereum instances, but also proprietary solutions. But there's a high diversity with limited convergence so far. And of course, and we need to talk about that later, there is now Swiat's regulated layer one, and it's well positioned here, we're going to talk about the layer. The asset layer stressed various tokenized assets that already exist like bonds, securities, deposits, stablecoins, but there is minimal standardization. So even money assets where you would expect most standardization show significant diversity in the implementation and most assets are platform specific with limited portability. And there's a need for asset information standards. So that was essentially my highlight when you described the assets of the asset layer. Please correct me here if that would not be your highlight. So the landscape is fragmented, so definitely in its description and also in its connectivity between these different assets, there is one thing which I really would feel comfortable calling a standard, namely this ERC20 token standard that we have, but it is only covering like a very narrow interface, which is already good enough, and I think it's focusing on the investor side, which is also important. And everything else is like proposal for a standard, I would say. And the time will show who has, let's say, the gravitas, so to say, to proclaim it in this standard. Yeah, then moving to my highlights of all your points within the service layer would be that simple threat-file services are operational, like basic asset transfers, but the more complex cross-platform services like atomic delivery versus payment or cross-border settlement is still largely experimental. And also there, a lack of standardized protocols means that, let's say, institution A's delivery versus payment can't interoperate with institution B's without bilateral manual work, right? Yeah, definitely, definitely. So it is, when we look at, I said, at the service layer, we need to provide something like delivery versus payment protocols and delivery versus delivery protocols. Because the requirements that we have from the business require for this are like exchanging collateral for security or in repurchase agreements, like security for cash or during an issuance of a bond, like the bond for the cash, so that they are much more complex protocols than just like transferring ownership from A to B, so in a very simple case. And I think in this regard, so we have so far no standardization at all, how these protocols, which interface they should follow, of course, it's wired, we have a solution at some other location, you will also find another solution, but then you need kind of to build adapters to each of them individually, so I think it will need to consolidate some regard. If you just look at the payment, like at the cash side, yeah, so I mean, for central bank money, we are getting some sort of interoperability interface, then with stable coins, we most probably can expect to have it in form of ERC20 token, then again, which of course, makes it a little bit easier. Then with tokenized deposits, you could lend with something else, yeah, and this you can see here, they have different kind of interface how to access them, and it's not consolidated yet, and it will take some time, I'm expecting. Then my summary of your access layer arguments would be that there is some maturity from leveraging existing standards, but still a fragmented wallet landscape, I would say that institutional access is more developed so far than retail access, and the user experience is still too complex for mainstream adoption on the access layer. This is a very interesting point, because if you think big from the perspective of going to mainstream, then I would claim, and I guess I would have a few fans here, is that 85% of the people do not care about wallets, about blockchain, about tokens. They care rather about having a specific asset with a specific property in their portfolio, and this portfolio should not be acquired to access, this portfolio should not be required to open another channel yet to someone else. Ideally they want to get it served by the existing channels. Of course, I have this ThreadFy perspective, but I think decentralization is good, yeah, and we should have this option, but people are actually looking for comfortable centralized services on decentralized infrastructure, and then if we look again at ThreadFy environment, then we come back to custodians, to custodians that are offering the post to their customers, a bit corporate, a bit retail, a bit other institutions. Looking now at this access layer again, then I think custodians will play here a significant role, just simply for the reason of efficiency and for the reason of comfort for the users. Even now I undertake the bold attempt to draw an overall picture, overall assessment of the SES architecture of the DLT-based financial market infrastructure, and I hopefully convince you, my overall assessment would be that the technical foundations do exist, and some production systems are operational, but real global interoperability across platforms and institutions is still on an aspirational level, and to me the critical gap is and remains standardization, particularly at the asset and the service layers, which currently prevent the network effects that are needed for a genuine global transformation of ThreadFy using blockchain, so did I convince you or would you draw an additional overall picture? I would say yes, but this is already like a second step from my perspective, and if you look at the model again, I mean it starts with the platform, I think we need to start at the lowest level possible to consolidate, and the lowest level possible to consolidate is like technology and like networks, and the reason why I'm saying this is, if you look so in the past, and the reason the different standards or quasi standards come out is that people are not able to meet at the same place, so they are like meeting at two different places and then they figure out how to do things, and then they call it their standard, and if we are able to kind of, and again looking from perspective of ThreadFy, if we are able to bring more and more players to more and more consolidated places that they meet, then they are also increasing like the chance to come to common standards at a higher level, and so for this reason we need to start at the bottom and then work step by step up, but of course things are happening also in parallel, it's not like a strict sequential process, but what I'm saying, we need to consolidate, we need to standardize, but we should always keep the scope small and start with the foundational layer and then move up, and that's also what motivated us to kind of start first with regulatory layer one as a blockchain where European financial institutions can meet under a credibly neutral governance umbrella, then first bring their use cases to it and at least consolidate this, let's say, execution layer which is actually not contributing to competitive differentiation, so they consolidate it in a cooperative for the benefit of all the members, and then they have, let's say, a roof under which they can meet to discuss the other things, and start consolidating at asset and service level. So it's so far we've looked at the SES, the present, the current state of DLT-based financial market infrastructure at least in Europe, at least in Threadfy, we've met the SES across the four layers of the ASAP model, but now let's move to the even harder question that is what should the to-be architecture look like for European DLT-based financial market infrastructures, maybe in three to five years, what are the critical architectural decisions that need to be made now to get us to this aspired target state? So we covered already a few topics because we kind of drifted from East State to what should be done, and one thing is we should see that we support this movement to convergence, to, let's say, a few consolidated platforms that we can bring assets on because without this it will be too fragmented, and every link between two platforms or two systems is introducing friction, and this friction, if it stays like it is right now, then it will definitely not be able to compete against the status quo. That's a very important thing, and now the question is, and again from Threadfy perspective, how do we govern such shared infrastructure? How do we introduce governance of it so that people are not afraid that it is some sort of profit extraction model and when they go in then, let's say, then the profits are extracted out of these people and they are locked in. So with regulated layer one, we kind of tried to provide an answer to that, but it's, of course, it's one of possible initiatives, and the second thing that needs to happen, we need to complete these missing parts, now independently on which layer they are from the architectural point of view, but we need to complete these missing puzzle pieces for the whole product for financial market infrastructure. What is missing is really having a payment leg which is scaled for different kinds of money, like for commercial bank money, for stable coin, for deposits for central bank money, but this is now coming, and I'm pretty confident that we will solve it. So if you look, for instance, at central bank money, so in Q3, 2026, so it was promised to have this in production, connectable via interoperability solution, so which is already a good thing, covering real payments. So payments, we need payments of different kinds and it need to be scaled, so currently we're still kind of in very, in very early phase from the perspective of trade back. And the second thing is, we are now so very busy with issuing things, but then they get stuck because they cannot be traded on a secondary market. And the pilot regime-- You mean issuing tokenized assets? Exactly, securities, tokenized securities, exactly, issuing these. But of course, we ourselves did already some secondary market trades, but it is not at a scale level yet, so this is something which is upcoming now, driven by pilot regime. And this needs to be solved because without a secondary market, a lot of these things does not make sense because having a barrier bond that is initially issued and then you are sitting on it and cannot trade it and also cannot give it as collateral for gaining liquidity, then you're at a dead end. This is something that needs to be solved and I'm also very much confident that it will be solved. It is already on the way. And the last thing is what we need to solve is we need to make these assets that are purely looking at them as financial instrument, which I've known already in a trade fight, but due to the fact that they're sitting on DLT, they are some sort of second class citizen because they are not included in eligibility frameworks. And the most prominent discussion is eligibility at ECB, that you deliver this as collateral and can get liquidity. And this is something which is also in discussion, but I'm assuming it will take two to three years or my personal estimates are to say on that. And then we get these things together. Then I would say we have completed the puzzle and then the time is where things can really take off. Yeah, I really like the completing the puzzle analogy or perspective. That's what we have architects for to make the puzzle pieces fit together in an effective way. Iwitza, one of the reasons why I wanted to discuss the topic with you is that you're not only a CTO, but you're a CTO of a company that contributes across the four layers outlined here. So let's now be specific about SWEAD's positioning using the framework again and going layer by layer, what does SWEAD contribute and how and what do you see other players' responsibilities? Maybe we can structure it by first focusing on the platform layer and focus on regulated layer one and then look at the other three layers that is asset, service and access layers, which from my perspective is SWEAD's actual right to play in this architecture. Yeah, the interesting thing is as we started, we started actually at service layer. So I mean, we did not realize that, no, not at SWEAD, but looking back at 2016, yeah, so at Deca Bank, we did not realize that time that we started at service layer, but what we soon realized is that we always, all the time needed to dig deeper and solve problems on layers below in order to be able to run these cases. And then we finally came to founding SWEAD in 2022 to cover everything end to end. And starting at the lowest layer, so platform, so we created a permissioned Ethereum network. And the reason why it is permissioned is because only in a permissioned network, so that's our hypothesis, is that you can clearly define who's responsible for what. And if you can define this, then you have a much easier work for regulated entities to do risk assessment and risk management because the basic, let's say, requirement to do it is to know who's responsible for what. And that was the reason why we created permission, why we created the contractual framework, describing explicitly these roles and responsibilities and connections, and also installing a governance around it. And as we started, we started as GmbH, so which is the limited in Germany. And we were aware of the fact that GmbH, or limited, is not a credibly neutral entity because the next day they could change the terms and conditions and then suddenly different rules apply. But we are now at a point where we have shown that it works, where we have taken innovation risks and we have already productive cases on it, so which gives people confidence that banks can integrate with such an environment and also bring assets to such an environment. And now we're carving this part completely out and bringing this within the regulated layer one initiative to a European cooperative, which is a credibly neutral entity that we want to design to manage this, let's say, shared transactional platform in the form of a blockchain. So that's our contribution number one at platform layer. And then on top of this platform layer, said in the beginning, everything revolves around assets. So you need software which is able to describe these assets and which is able to run bookkeeping on these assets in the form of a token on blockchain. And from our perspective, we are covering there everything which is kind of needed by regulated entities like covering tokens which are compatible with electronic securities act for instance here in Germany, or compatible with the pilot regime, but we keep, we are also aware of the fact that depending on your needs, eventually you need different formats. So there is no one talking to rule them all or a silver bullet which kind of solves all problems. So we're keeping this as open extension point from the architectural point of view. And depending on use case drives that we have, we also we are always ready at all time to implement a new let's say token format in this regard. So this is our tokenization engine. And now going to the service layer so with what we are offering there is basically two things here. So the first thing is we are offering a delivery engine which is able to assemble more complex delivery protocols which I mentioned like delivery versus delivery or delivery versus payment. And this can happen with assets within the same ledger, but it is also able to connect with other ledgers sitting outside let's say a spire domain. And in this regard it does not matter actually if they are centralized or decentralized. So ledger is a ledger basically. So centralized or decentralized is a question of operations how you run it and who's responsible for it. So what we did so far is to integrate with Euro system during the trials last year and we will also implement with Pontus which is let's say the new track that ECB started for bringing the payment lag into scale production. And we also implemented with JPMorgan Kinexus for tokenized deposits for what formerly was called JPMorgan coin and as you can see here we are also keeping this as extension point because right now we cannot kind of say what in some we need. So we need to keep it open in this always we are use case driven. So if our customers have a requirement and we would add another payment like type implementation to support and this case in a delivery protocol. Yeah. And the final thing is on the excess layer. We are aware of the fact that we have a decentralized network and we always give the option to our customers to deploy a node on their own side but in a current phase where people are still kind of going over the verge so it's much more easier to have complete packages that can be booked and later migrated on site and so for this purpose we are providing also simple let's say excess products which make it easy to get into the system and it's especially easy for custodians to join or verify institutions to join the network with low effort. So that's basically our contribution mapped to the four layers. Take the mention. Yeah thanks for guiding me through Sweden's contribution across those four layers. One observation is that first and foremost it's interesting to see a DLT player playing all four levels at the same time particularly on the infrastructure level which is a super competitive layer and if this wire play on the infrastructure layer plays out works then it'll be super promising for Sweden because infrastructure is power. If you really contribute on or are successful on the infrastructure layer it gives a lot of power to influence the space. The interesting thing here Michael is that we're not doing it for power so this is not typical as your explanation kind of reflects it. So actually we did not want to do it to be very honest. It would be much better for us if somebody else solved this problem but since nobody solved it and we wanted to go for scaling then he said okay we are going to touch this and now we want to kind of package it in a way that it gets even more open for let's say a larger set of people especially targeting European financial interests so that we do not see it as a competitive contributing to competitive differentiation but rather something which everybody should profit from and then competition happens on top of it at asset and service layer and exit layer. If it's too close our very interview let's do what architects can do best that is look at the long game lower our time preference. So looking 10 years out do you think we'll have successfully built a genuinely new generation of financial market infrastructure on DLT or will DLT end up being a back end optimization technology to existing systems that look largely the same from the outside? What do you think? So what I would say is we are successful when nobody is talking about DLT and wallets and brand keys and everything is like hidden under the hood and just like you do not talk about JavaScript and HTML in your browser you just go to the website and use it. So I think that that's a measure of success and I also think we have that there is such a velocity when you are like for a decade in an area and you still see a lot of energy and you yourself have still a lot of energy to push things forward then things are in motion so they will come to a point where all these promises are realized especially now looking at all these aspects that need to be covered all these puzzle pieces that need to be collected so a lot of very smart people are across the globe on a way for building these puzzle pieces and bringing them together and I'm fully convinced that it will happen and having 10, 20 years for adoption of such a huge change is nothing actually so I'm counting in decades and not in months to be 100 so I'm now for 10 years already and I'm investing at least 5 more years for this. Yeah a really good point I mean all these conversations only started with the emergence of Bitcoin in the first place so this is still a super young technology and for an emerging technology to now have conversations about the long term impact on financial market infrastructure is actually fast right so if you had told me at the inception of Bitcoin or only 5 years ago that architects would have such a conversation today I would have smiled probably but here we are. Absolutely if you look back you see that we have climbed Mount Everest but if you look forward you see another Mount Everest to climb so but yeah you should not stop. So I appreciate your hopeful but realistic long term vision I believe genuine transformation is possible but we need to acknowledge the path dependencies and the challenges we observe on a daily basis and I think the importance of getting architecture today right now is one of the key levers to enable that very transformation all the DLT practitioners in the space have. Yeah absolutely absolutely so and architecture including not only technology but also the legal, contractual and regulatory party. Yeah this has been a masterclass in thinking about DLT infrastructure beyond the hype cycle and all the pilot announcements and pilot implementations we observe on a daily basis in the news I think the architecture lens gives us more clear way to understand where we are where we need to go and what needs to be done and who needs to do what. So thank you for bringing such technical depth and practical experience to this architecture conversation and to our audience thanks for listening to Bitcoin, Fiat and Rock'n'Roll, thanks Editha for your insights and for helping us map the architecture of Europe's emerging BLT based financial infrastructure do connect with us on YouTube linked in and our expert community on Telegram both in German and English for details check the show notes and by the way Ibiza is a engaged member in both geners English and German so if you do have questions to Ibiza drop them there I hope Ibiza you will then be happy to answer some of the questions and also excellent and also visit our website bfrr.com for more detailed analysis and complete show notes from this episode including links to the IMF ASAP model paper make sure to subscribe to bfrr wherever you get your podcasts and join us next week when we'll be exploring another critical development in digital finance until then this is Bitcoin, Fiat and Rock'n'Roll bringing Europe's perspective on digital assets to the world thanks for listening. Thank you very much for the invitation like the views expressed are solely the personal opinions of the hosts and are provided for informational purposes only this podcast does not offer financial or investment advice always conduct your own research and make well informed decisions before investing please be aware that the hosts and guests may hold cryptocurrencies or digital assets discussed in this episode.