What It Takes to Bring Institutional Finance On-Chain: Lessons from JGB Repo

Transcript

[music] Hi everyone. Um I'm Masa, founder and CEO of Secure Finance. So I have uh 17 years in um interest rates and FX derivatives and moved to onchain finance and we built um on both cryptonative lending market and then uh institutional financial infrastructure. So this year we joined uh the industry working group called JGB onchain repo. So um in this working group even a basic question would take uh weeks of professional

discussions and then that conversation um gives us a great uh idea of shaping a new infrastructure and how we can integrate uh onchain finance into the existing financial ecosystem. So this um talk is about uh this discoveries. Um first um let me share what we have now. So this is the mapping we use when we talk to me banks and trat files. Each stratfire function on the left where it sits in our protocol on the right. So as you can see on the right hand side there's

clearing house brokers and CCPs and all of these financial institutions are communicating each other using the files and communications which takes a day or two for the reconciliation that's kind of pain point and on the left hand side what we did because on ecosystem there's no finance institutions like that we had to migrate all of these functionalities into one single protocol stack. So that's kind of what we have on the cryptonative [clears throat] uh lending market.

So I'm not saying we should replace existing uh infrastructure into uh crypto but this is more like how we can explain the the mapping with existing uh system into our protocol so that uh traditional finance people can understand uh how to connect uh the trusty and defy. So yeah so for the all so one protocol is like a from execution collateral and settlement risk and maturity. This is basically the life cycle of a finance protocol and we had to put all of these

into one single stuff. But uh when we started talking through the working group we realized that uh we already have a super efficient established system why we have to replace them instead we need to think of a way to integrate and co [snorts] co-work together so this year in February we announced that integrating tokenized money market which issued by UBS which calls a mint. So this is a traditional financial asset tokenized issued on Ethereum mainet but with the uh transfer restriction. So it's a fully uh regulated uh securities token securities on chain and then we migrated and that

opened up a discussion with uh current traditional finance. So um so we have both crypton native uh stack and also traditional uh institutional wholesale um like a stack. But uh on our protocol we should cover from execution qual settlement life cycle within our protocol. But when we talk to institution wholesale they already have it. So the question mark is kind of boundary we need to find out. So yeah before deciding that boundary we had to establish what the onchain asset

actually was. So really basic question so what exactly is an onchain JGB is Japanese government bond. What is the tokenization of it? And there's basically the two major design concept. I think on the left hand side is more familiar to kind of tokenizing discussions. One is more like a a wrapper style or clay model. So the to the JGB will be kept in a custodian and then mint tokens and then after tokenization then we can just use it on chain. That's come one this is one way and a second approach that came out of

the discussion throughout the working group is a native book entry model. So this is a basically uh in Japan when we wanted to move from the paperbased uh ownership booking system into electronic management uh booking system we established a law to make it possible. So in Japanese it's called a furyo and then uh it's book entry system. So we think um the electronic version of Japanese government bond could be onchain if we if we match the same level

of uh requirements that's managed by the system. So it's like uh okay we have a electronic version of JGB like a JPEG but we can also have another version like a PNG it's just a matter of like a different style so that even if the JGB came on chain on the distributed ledger then we can think this is a native um JGB to preserve the same legal nature. So in this way the existing financial institutions can treat this in the same system because it's basically essentially the same thing. So that way it's this kind of discussion shape our

architecture discussion and this design decision. So uh really helpful. So and yeah so the next question is who is responsible for each part of the transaction. So this is the architecture we are proposing. So it's basically just one single repo trade and you don't need to read the detail but look at how many responsibilities uh sit around one trade. both counterparties, their operation teams and the venue, execution venue, integration and the ledger and also account manager that can

um basically the manage the native JGB and the funding arrangements all have to fit together. Um so the blue color is basically the onchain part. So please note where the ledger step starts. So after operations confirmation then it goes on chain. So usually kind of defy is basically using metam mask and just click the button and then just execute it. It is a bit too direct. So when when we talk with the traders, hey they want to make the deal and make the it done then this done information is go to their uh back office and then they

check they need this check system. So traders done and then goes to the uh operation team to actually trigger and assign on a trade on both both side and then it goes on chain. So, so we have to agree on those uh system. So, once those responsibilities are clear, then we can go back to those question marks. So, back to the grid here are the answers uh for the institutional column basically on the left hand side. Execution stays with the existing venue and a contract layer handles agreed trades and settlement and

life cycle and it does not become a CCP or uh take over the existing obligations and then custody roles stay with the reconcile sorry responsible um institutions. So we use custodians and allocation DVP happen on the the shared ledger and each part participant connects um through its own booking approvals interfaces and but the benefit of using onchain is parties just refer to the one single source of truth that's written on blockchain. So there's no uh no reconation. Yeah, that's really the uh benefit of using onchain and for yeah

and execution venues are I think already very well developed. So like a onchain club order book system or RFQ system there's a very famous like a trade web or like a Jbond or this system is pretty good. It's already installed in the trader system. So we don't want to basically uh replace or uh cannibalize instead we want to collaborate and then we can provide most post trade management system. So in this way we find a way how we can collaborate together.

So yeah but however this workable architecture is only part of the case and why would anyone pay to connect to it? So yeah, a trade can be fully collateralized but still use a credit line, need liquidity and requires someone to hold a buffer. That's kind of reality. Uh with banks, you know, in DeFi that's it like a over collateralization can avoid the credit uh problem. But with banks even with the overcautilization but still needs uh credit lines, credit limits, liquidity, balance sheet usage. So and a lot of

regulatory constraints. So and also when you go to banks, you need to understand Basel framework and liquidity balance sheet uh constraints well enough to know where is the pain actually sits. So yeah, it's kind of like a the thing we always uh have in mind and but the thing is it's very hard to find out the pain point. So where's the cost because it's hidden usually it's invisible. So many practices you know basically the trade goes very smooth on institutions because it designed this way and uh but if you look into detail the single trade like a

flow like a purchasing and bonds and settlement okay bonds settle here on the left and between the funds arrive there's actually a timing gap so this is a gap some somebody is holding it's via could be via preunding or using credit line or intraday like a BOJ overdraft. So some system is used somebody is paying the cost to fill the gap. So this could be the kind of hidden pain point or kind of um frictions.

So if it go on chain it should connect together to make it happen to to truly the DVP which means derivative versus payments. So we want to think about this blue line is kind of benefit if you want to reduce the cost like a integration cost, transaction cost, operation cost, liquidity charges is and a benefit is greater than that then we can finally uh integrate this onchain system on existing financial system. So those kind of discovery of the painoint is really the key and another point in our community like

a privacy. So usually it means protecting personal data or hiding identity in a financial institution. It means something closer to information control and driven by internal control and market conduct regulation. So information barriers between desks, clients and research. There's firewall and mandates and delegated authority. Not everyone of working for the company can do everything. basically who may act and see and done on behalf of the company and approval and hierarchies and visibility and sign off follow the

organization's uh structure. So the requirement is not hide everything uh it is a right people see the right um trade state according to the mandate. So yeah and in multi-firm discussions through the working group then yeah I think this becomes quite obvious. So yeah, here's the implication for Ethereum builders including myself and design kind of visibility as part of the permission model uh from the scratch from start and shared state is great but does not have to mean uh everything has

to be public state. Some ledger designs make this easier than others. Um, and none of these answers came from a single sales meeting. It actually throughout the weeks long, monthsl long conversation amongst the multi-firm industry working group and this helped uh design a scope of the system architecture. Um yeah it did more than uh validation of the technology and so we I shared the legal like a nature of the JGB. Uh once this legal um or asset nature is defined then the next decision

follows quite naturally and then mapping onchain trades to the ex of the existing system to the uh of the existing system. So um then it allows us to reuse the existing um libraries or um knowledge bases. For example, for the contract offchain contracts, there's a repo contract global master repo agreement called the GMA. This is globally. So we can apply the same existing global master agreement and connect to the onchain. So in this way we don't need to create this offchain contract from scratch and the

same idea can apply to the data model. So in usually we have to develop our own data model the strct but uh if you follow the existing um model then data model will be okay maybe we can use like a is a CDN model and then just uh ISO 2022 or something then and then finance institutions are super familiar with this um communication. So it yeah I think this is the way uh how we can connect. So and then you know in terms of business development uh on a

defi side it takes uh you know just a bizdev side but uh for institutions it's really kind of like a year long or more many more years of the continuous conversation than building relationship and then the these questions didn't come early it came quite later. Um so well just basically the legal record or something just takes weeks then the market architecture uh idea finally came out after months of discussion. So these experiences help me kind of summarize

the kind of key takeaways of five things questions I would use before building the next institutional product. So this is the last slide. Um these questions uh inform both um tracks at secure finance and EVM lending model and institutional infrastructure. Um the lesson is not that one architecture wins. The legal asset, the economic problem and the market's responsibilities must shaped the design. Um yeah the same same questions are useful to Ethereum builders and even when the result information is different. So yeah please

take a look and question number one is about asset. What is the holder legally own? It's kind of tokenizing and then which is the claim or wrapper or is this native asset and constraint who carries today's cost? What is the settlement gap or who is paying the gas uh on the network and who must agree and act it is not the blockchain network. It's more like the participant networks and who is involved on operation team and and yes and then the traders. So and also the see the boundary what we should build and what we should connect. So defining the boundary is something quite

important and also the finally the control and who may act on on behalf of what the mandate. So this kind of control design might be critical. [clears throat] So yeah define the asset find the constraint and draw the boundary. Yeah. So the code the legal rights and actual workflow have to agree. So that is the work of bringing institutional finance on chain. So thank you very much.