20261022_【DCC】Tokenized-JGB-Onchai- Repo-WG_Interim Report

Transcript

1. CONFIDENTIAL / Discussion Purpose Only Digital Asset Co-Creation Consortium (DCC) Tokenized JGBs and On-Chain Repo WG | Interim Report October 2026 Digital Asset Co-Creation Consortium © Progmat, Inc. English reference translation | Japanese original prevails
2. CONFIDENTIAL / Discussion Purpose Only Contents Executive summary #1 Overview of Progmat, DCC and this WG #2 Background and rationale for on-chain finance and tokenized JGBs #3 Methodology for tokenized JGBs #4 On-chain repo: overall structure and components #5 Additional issues: tokenized JGBs and on-chain repo #6 Next actions toward practical implementation of tokenized JGBs English reference translation | Japanese original prevails
3. Executive summary Background and rationale On-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only • Japan's tokenization market has grown to around JPY 0.8 trillion in AuM, chiefly through new retail products, and is expanding into more advanced institutional trading. • Global DLT standardization aims to maximize capital efficiency. A consensus is emerging on its benefits in post-trade processes, especially settlement and collateral management. • In Japan's JGB repo market of over JPY 250 trillion, 24/7 and just-in-time processing can meet real demand in non-CCP-cleared trades, overseas hours and areas outside BOJ overdraft coverage. • The main proposal for tokenized JGBs (tJGBs) is to manage book-entry JGBs themselves on-chain as electronic records of the book-entry transfer account register, rather than tokenizing registered JGBs or linked rights. • On-chain management accounts (OC accounts), synchronized with DLT, change only the management method while retaining the securities' legal status as book-entry securities. Tokenized JGBs Methodology • DLT processing must meet the Book-Entry Transfer Act's requirements for transfer applications and notifications, include all required data, and implement hierarchical processing among account management institutions. • The DLT node itself could constitute the authoritative tJGB account register. However, personal data and similar information are unsuitable for DLT storage. To support multiple DLT standards, the main proposal uses OC-account records in a new system operating 24/7 and continuously synchronized with DLT as the authoritative register. • Existing account management systems serve as hubs for surrounding interfaces and archival-file creation. Synchronizing OC-account data only as a copy during operating hours minimizes changes to existing systems. • Start with on-chain trades under a single direct account management institution, which need no CSD link (the BOJ is the JGB CSD). In parallel, examine cross-institution transfers: a DLT lock triggers an API call to the CSD, and transfer becomes final after the CSD completes its record. • DLT is not itself excluded as a method of electronic recording. Before implementation, however, confirm consistency with BOJ operating rules, including processing hours, with the BOJ and relevant authorities. • The main scope is post-trade processing of non-CCP-cleared bilateral trades, retaining existing execution venues and master agreements, rather than a DeFi-style TokenVault / fully on-chain model. • A reasonable near-term focus is to test relief of constraints in non-CCP-cleared markets, including nonresidents, through cross-border and intraday use cases. On-chain repo Overall design and components • No new master agreement is proposed. Add a digital-asset annex to existing New Gensaki master agreements or the GMRA, retaining existing clearing scope and related arrangements. • Straight-through matching, settlement and collateral management, linked to tJGBs and TD/SC, enable repeatable hour-based trades 24/7. Intraday value lies in two DvPs at start and end, with repeatable short-period management of contracts, balances and interest, rather than same-day settlement alone. • The system comprises tJGB and TD/SC issuer nodes, a post-trade standards execution layer and integration platforms, connecting multiple platforms, standards and existing operations. • Identify and test remaining pain points beyond needs already met by BOJ intraday overdrafts, including ineligible nonresidents and funds, overseas hours and foreign-currency funding. Tokenized JGBs Next steps toward practical implementation • For hands-on testing, build a tJGB / TD / SC sandbox on Canton Network, connected to multiple domestic and overseas repo and collateral platforms. • Repo-market sandbox participants who accept the terms, including cost sharing, can access partner platforms' actual interfaces, processing experience and confidential information, and use the system to test intraday, cross-border and cross-platform cash / collateral management use cases and implementation benefits. © Progmat, Inc. #2 English reference translation | Japanese original prevails
4. CONFIDENTIAL / Discussion Purpose Only #1 Overview of Progmat, DCC and this WG © Progmat, Inc. #3 English reference translation | Japanese original prevails
5. #1 Overview of Progmat, DCC and this WG CONFIDENTIAL / Discussion Purpose Only What is DCC? | A cross-industry framework for creating value together Purpose Co-create new cross-industry ecosystems across the full range of digital assets Share the latest knowledge Co-create products How it operates 1. Acts as a comprehensive non-disclosure agreement, allowing WGs and projects involving multiple parties to proceed flexibly. Adjusting the scope of disclosure avoids a separate NDA each time. 2. Forms working groups (WGs) for cross-industry or highly innovative themes, with voluntary participation. Joint study and proposals 3. Limits access to confidential information so members can flexibly pursue individual projects together. 4. Decentralized governance of products Key points 1. No joining fee or participation fee Digital Asset Co-Creation Consortium (DCC) 2. Email the application (Word; no seal required). The secretariat completes onboarding and sends access to the members’ website. 3. Option to keep the company name undisclosed © Progmat, Inc. #4 English reference translation | Japanese original prevails
6. #1 Overview of Progmat, DCC and this WG CONFIDENTIAL / Discussion Purpose Only What is Progmat? | The secretariat operating DCC Its assets and track record include a network of hundreds of companies working on leading-edge themes, industry expertise, and operation of Japan’s largest ST platform by market share (plus related patents). It provides the multi-chain / cross-chain implementation and integration with payment instruments such as stablecoins (SC) and tokenized deposits (TD) needed for market growth. Other industry bodies Company: Progmat, Inc. Founded: 2 October 2023 Capital: JPY 100 million; company with a statutory auditor Governance: 7 directors and 1 statutory auditor Representative: Tatsuya Saito Location: WeWork, 9F Marunouchi Kitaguchi Building, 1-6-5 Marunouchi, Chiyoda-ku, Tokyo Team: 27 (including 4 contractors and 1 concurrent secondee) 6.4% 14 organizations Tech / consulting Cryptoasset exchanges 19 organizations Lead primary markets; standardize specifications Exchanges / securities firms 34 organizations 6.4% 4.3% 4.3% 4.3% 11.6% 5.0% 2.7% Issuers / managers 150 organizations 7% 17% DCC 367 organizations 5% 41% 9% 17% Fin. inst. / payment providers 62 organizations Patents • Token-issuing trust system (registered Apr 2021) • Electronic register system that completes transfers of rights (Mar 2022) • SC remittance system (Swift integration; Apr 2026) Lead secondary markets; integrate settlement infrastructure Expertise in financial infrastructure and advanced technology Create new financial products / customer experience 4% 61 organizations Shareholdings 6.4% 6.4% Law / audit firms, etc. 27 organizations Non-consolidation threshold 42% Multi-chain / cross-chain implementation • Successful technical verification of cross-chain settlement of digital securities using stablecoins (Apr 2023) • Launch of a proof-of-concept project for stablecoin-based DvP settlement in the security-token secondary market (Aug 2025) • Collaboration on a new digital-securities scheme using public blockchains and stablecoins (Jul 2026) * Employee / officer stock options are in addition to the holdings above. © Progmat, Inc. #5 English reference translation | Japanese original prevails
7. #1 Overview of Progmat, DCC and this WG CONFIDENTIAL / Discussion Purpose Only DCC membership | Businesses developing products, and experienced firms and specialists Other industry bodies, etc. 27 organizations Issuers / asset managers Law firms / audit firms, etc. 14 organizations Technology / consulting 4% 7% 17% 61 organizations Cryptoasset exchanges 150 organizations Digital Asset Co-Creation Consortium 41% 367 organizations 5% 19 organizations 9% Exchanges / securities firms 17% 34 organizations Financial institutions / payment providers 62 organizations © Progmat, Inc. #6 English reference translation | Japanese original prevails
8. #1 Overview of Progmat, DCC and this WG CONFIDENTIAL / Discussion Purpose Only DCC participation | Steady growth as the market expands and industry themes evolve (organizations) 400 367 orgs. Organizations in the Digital Asset Co-Creation Consortium (DCC) 380 307 orgs. 360 340 265 orgs. 320 300 280 260 197 orgs. 240 220 200 180 91 orgs. 160 140 120 50 orgs. 100 80 60 40 20 0 4 6 8 10 12 FY2020 2 4 6 8 10 12 FY2021 2 4 6 8 10 12 FY2022 2 4 6 8 10 12 2 4 6 FY2023 8 10 12 FY2024 2 4 6 8 10 12 2 4 6 8 FY2025 © Progmat, Inc. #7 English reference translation | Japanese original prevails
9. #1 Overview of Progmat, DCC and this WG CONFIDENTIAL / Discussion Purpose Only WG role | Define a feasible method and real demand that outweighs coexistence costs To close the gap with overseas markets, we aim to tokenize JGBs after investment funds and equities. Given legal constraints (non-book-entry instruments impose heavy administration and tax disadvantages) and existing infrastructure, we must identify feasible tokenization methods and real demand that outweighs the cost of coexistence with, rather than replacement of, that infrastructure. Tokenization track record Barriers to tokenization in Japan Overseas Japan Legal constraints Incumbent infrastructure Rationale / real demand 1 JGBs ◦ (↑) Signs of rapid growth Widening gap △ Many issues remain Non-book-entry: high admin burden / tax disadvantage × Strong incumbent systems Book-entry infrastructure is the de facto standard ◦ Cross-border demand Expected gains in repos with overseas markets 2 Municipal bonds - - ◦ Legally permitted Law passed in 2026 ◦ Little cannibalization No non-book-entry segment exists ? Further study needed 3 Corporate bonds ◦ Multiple commercial cases ◦ Multiple commercial cases ◦ Legally possible ◦ Little cannibalization Non-book-entry segment is managed in Excel ◦ Marketing-led demand Need to understand investor information 4 Equities ◦↑ Rapid growth △ Deals under development ◦ Legally possible × Strong incumbent systems Book-entry infrastructure is the de facto standard ◦ Strategic-holding vehicles Demand for micro-shares and enhanced trading 5 Investment trust beneficial interests ◦↑ Rapid growth led by MMFs △ Pilot-fund stage × Strong constraints Non-book-entry transfers require certificates △ Depends on book-entry use Existing infrastructure for book-entry securities ◦ Demand led by MMFs Adoption expected via SC and interest rates 6 Beneficiary-certificateissuing trust (JS) beneficial interests - ◦↑ Rapid real-estate ST growth △ Some constraints Complex structures are essential ◦ Little cannibalization Non-book-entry segment is managed in Excel ◦ Led by real estate Demand for unlisted public offerings to retail investors 7 Other trust beneficial interests - - △ Some constraints Industrial Competitiveness Enhancement Act special measures required ◦ Little cannibalization Primarily managed in Excel ? Further study needed 8 Deemed securities, e.g. collective investment scheme interests - - △ Some constraints Industrial Competitiveness Enhancement Act special measures required ◦ Little cannibalization Primarily managed in Excel ? Further study needed © Progmat, Inc. #8 English reference translation | Japanese original prevails
10. #1 Overview of Progmat, DCC and this WG CONFIDENTIAL / Discussion Purpose Only Current stage | Publish consensus on priority issues, then move to hands-on testing The study meetings begun in May 2026 form Phase 1, the desk study, which organized priority issues such as methodology for tokenized JGBs and likely sources of real demand. In step with government and regulatory moves to promote on-chain finance, we will publish the findings to advance the industry and move to hands-on testing toward practical implementation. 2026 Phase 1 Desk study May 5/29 Announcement / meeting preparation Study kickoff Phase 2 Hands-on testing 6/16 7/7 7/28 8/18 Study meetings (online / every 3 weeks) 9/8 9/30 Oct Study discussions conclude Publish interim report Invite Phase 1 participants; begin preparations and environment setup (details follow) Government / regulators 2027 Share progress as needed Announce Phase 2 Nov ~ Phase 2 kickoff Report on study progress Spring Publish interim report Requests (if any) Current stage © Progmat, Inc. #9 English reference translation | Japanese original prevails
11. CONFIDENTIAL / Discussion Purpose Only #2 Background and rationale for on-chain finance and tokenized JGBs © Progmat, Inc. #10 English reference translation | Japanese original prevails
12. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Japan’s on-chain finance market | Growth through new products for existing customers In Japan, tokenized projects have approximately JPY 0.8 trillion in AuM and ST issuance totals approximately JPY 0.4 trillion (publicly disclosed projects as of end-September 2026). Real-estate STs, which offer a new type of real-estate investment product, account for most activity. Unlike overseas markets, Japan is centered on retail investors with securities accounts. (JPY 100 million) (projects) 9,000 Outstanding ST projects (public): total B/S assets in the SRS; zero at redemption 8,500 Cumulative ST issuance (public): includes redeemed projects 8,000 Cumulative number of ST projects (public): includes redeemed projects 130 >8,148 120 99 projects 7,500 7,000 110 100 6,500 90 6,000 5,500 80 75 >4,323 5,000 4,500 60 51 4,000 >3,003 3,500 3,000 70 50 40 33 2,500 >1,474 2,000 15 1,500 1,000 >32 500 4 30 >809 20 10 >235 0 0 4 6 8 10 2021 12 2 4 6 8 2022 10 12 2 4 6 8 2023 10 12 2 4 6 8 10 12 2 2024 4 6 8 2025 10 12 2 4 6 8 10 2026 Source: Progmat, based on public information. Includes private placements with disclosed amounts and announced / planned public offerings; deals that may be cancelled are counted only after issuance is confirmed. © Progmat, Inc. #11 English reference translation | Japanese original prevails
13. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only A new phase of on-chain finance | Effects now extend into mainstream financial business Existing STs have primarily been new products for retail investors. Bringing bank deposits and other payment instruments on-chain creates common rails with book-entry securities such as JGBs, investment funds and equities. Enhanced trading then benefits institutional investors too, creating game-changing opportunities and threats for established financial businesses. Existing STs New STs “New products” for retail investors “Enhanced trading” for institutional investors Country A Conversion vehicle (SPV) Movable assets Backing assets Linked rights Register Self-offering Receivables / bonds / interests New investor segments Real estate Cross-border shared securities / cash infrastructure Book-entry securities Existing trading infrastructure (JGBs, funds, equities) Institutional investors Common rails On-chain investors TD / SC (deposits / beneficial interests) Infrastructure for unlisted / non-book-entry instruments Fractionalization • securities taxation • marketing Country B New trading infrastructure 24/7 • intraday • improved capital efficiency © Progmat, Inc. #12 English reference translation | Japanese original prevails
14. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only External pressure | U.S. policy acceleration also stimulates demand for Treasury backing On-chain finance has grown too significant to ignore, raising concerns that failing to act proactively could forfeit future leadership in finance. Accelerating on-chain finance is also rational for the U.S. government as a borrower, because it directly creates demand for U.S. Treasuries as backing assets. Backing assets State Store value / frequent interest Tokenized MMFs Govt. bonds Credit creation Banks Deposits * Backing assets Stablecoins Store value / flexible transfers Expected returns / flexible trading Actual fund-raising entities vary by case Crypto assets Expected returns / flexible trading Security tokens Risk-capital provision Expected returns Risk-capital provision Equities / corporate bonds ETFs Expected returns Expected returns Irreversible expansion * Individuals / companies Individuals / companies On-chain individuals / companies Transparent backing assets High liquidity / instant conversion Store value / earn interest Key On-chain Traditional off-chain method * Permitted overseas; regulatory easing is needed in Japan © Progmat, Inc. #13 English reference translation | Japanese original prevails
15. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Why on-chain? | Maximize capital efficiency through common standards; DLT is the shared answer For global financial firms and institutional investors, infrastructure reform aims to maximize capital efficiency, or prepare for others doing so: offensive and defensive motives align. Building new systems to common standards better supports scalability and external integration. At present, DLT is the most widely shared technical answer. Common goal: maximize capital efficiency without constraints, or prepare for others doing so □ Trading and instant settlement 24/7, irrespective of time zones or system closing hours □ Unified cash / collateral management across countries, products and systems (ledgers) ▪ Consider effects on connected peripheral systems as well as the target system Modify existing systems ▪ Incorporate incumbent-system specifications and replacement schedules ▪ Secure IT-department / systems-integrator resources (staffing constraints) Build new systems □ Explore options free of the constraints of existing systems Use proprietary standards □ Likely the quickest route when a single company can implement everything ▪ Limited scalability and difficult external integration may defeat the goal Use common standards Do not use distributed ledger technology (DLT) □ Explore options free of the constraints of existing systems □ Scalability / external integration support achieving the future goal ▪ No progress or learning until a non-DLT common standard emerges Use distributed ledger technology (DLT) □ Explore options free of the constraints of existing systems □ Scalability / external integration support achieving the future goal □ Today’s most widely shared standard minimizes the risk of falling behind The key is common standards. DLT is one means, but is also today’s most widely shared solution. © Progmat, Inc. #14 English reference translation | Japanese original prevails
16. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #Why go on-chain? | Consensus on the benefits for settlement and collateral management Across the stages of institutional transactions such as repos, where overseas markets lead, post-trade is seen as offering the greatest benefits from moving on-chain. In particular, settlement and collateral management can be optimized by integrating on-chain infrastructure, driving near-term international initiatives. Assessment of the case for moving on-chain 1 Execution 2 Clearing Matching, netting, settlement instructions, etc. Settlement 3 6 7 8 9 Collateral management 5 Post-trade 4 Price discovery and liquidity are already concentrated on existing electronic trading platforms. Can a new decentralized platform offer value to participants who can access it more readily than existing infrastructure? Central clearing requires a legal entity, so existing CCPs must first support on-chain activity. Outside CCP clearing (e.g., intraday), calculations and processing could be automated and reconciliation steps reduced. Settlement architecture Remove intermediaries' multilayered account-based structures and inter-institution processes, reducing intermediation costs and risks, including the large capital, liquidity and collateral requirements they entail. Settlement speed / timing Expand settlement windows constrained by institutions' business hours and batch processing through 24/7 operation. Precisely timed, fast intraday settlement can reduce funding costs. Composability Replace manual, transaction-specific links between interdependent trades (e.g., repos conditional on a cash-bond purchase) with conditional, atomic automation on a common ledger, minimizing failure and timing-mismatch risk. Visibility / optimal allocation Unify the overall view of collateral held in separate silos and dynamically optimize allocation, shifting from collateral held "just in case" to "just in time" supply. Process efficiency Automate and accelerate collateral management to address exposure from slow variation-margin transfers and inefficient substitutions / cash-in-lieu payments, minimizing exposure, operational risk and workload. Portability / mobility Use interoperability to move collateral locked in specific systems flexibly across multiple systems and locations, using it efficiently across the network as a mobile resource. Unlocking idle assets Tokenize assets that are hard to move or use due to high costs in conventional infrastructure, releasing them as eligible collateral and maximizing funding and liquidity efficiency through a broader collateral pool. English reference translation | Japanese original prevails © Progmat, Inc. #15
17. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #On-chain settlement hours | 24/7 operation without cutoffs expands overseas investors' opportunities For example, book-entry JGB settlement is concentrated within limited Japanese hours. London and New York business hours fall after settlement deadlines, requiring instructions to be finalized on the preceding business day. Systems linked to 24/7 DLT could expand overseas investors' trading opportunities. (JST) 00:00 03:00 06:00 09:00 12:00 15:00 18:00 21:00 24:00 Overseas investors / global custodians (London local time 09:00-17:00) Overseas investors / global custodians (New York local time 09:00-17:00) PSMS *1 Non-resident cutoff [12:50] 07:00 Pre-Settlement Matching System (PSMS, JASDEC) Automated matching (JGB matching deadline) JGB core time *2 [16:30] Telephone matching only (manual processing) 08:30 Book-entry institution online input (BOJ-NET messages) BOJ-NET online input hours 08:30 JGB book-entry / DvP system (BOJ-NET JGB services) JGB DvP settlement hours Book-entry account register at each account management institution (existing account system) Book-entry account register at each account management institution (new DLT-linked system) FOP transactions only Japanese weekday daytime only (varies by account management institution) Operates alongside / linked to DLT DLT operates in parallel with existing systems External network / DvP functionality (distributed ledger technology, DLT) 24/7 operation - no cutoffs *1 Automated JASDEC matching deadline for non-resident trades; thereafter, telephone or other manual matching. *2 Deadline for JGB DvP; thereafter, separate reopening is required and, in principle, only FOP is available. © Progmat, Inc. #16 English reference translation | Japanese original prevails
18. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #On-chain cash / collateral management | Just-in-time funding beyond BOJ intraday overdraft coverage Outside BOJ intraday overdraft coverage (including foreign-currency funding), buffers for expected payments and unsettled balances create intraday cash surpluses, while prefunding and collateral substitution tie up collateral, sometimes twice. Cross-system management and instant transactions can support just-in-time funding and improve cash / collateral efficiency. As-is: intraday cash / collateral management To-be: greater cash / collateral efficiency (Entities, trades or hours ineligible for BOJ intraday overdrafts) *1 (Private repo transactions complement areas outside BOJ coverage) [+] "Just in time" Pay Pay Unsettled balance (gridlock) Time Repay [-] Collateral New collateral is pledged before old collateral is released, causing a period of double encumbrance and scope to improve collateral efficiency. Cash Receipt Buffers for expected payments and unsettled balances create surplus cash, leaving scope to improve cash efficiency. [-] Collateral released Time Funding (sale) Funding (sale) Pay Pay Partial substitution Substitution (temporarily tied up twice) complete Unsettled balance (gridlock) Repay (repurchase) On-demand funding and atomic collateral substitution minimize total collateral needs and optimize allocation. Collateral tied up (sale) Collateral tied up [+] Receipt [-] Collateral Cash Credit funding, etc. [-] [+] "Just in case" [+] Time Raise exactly the cash needed each time, using flow visibility, scheduling and automation to minimize buffers and surplus. Collateral released (repurchase) Time Additional collateral pledge (additional sale) Partial collateral substitution *1 Intraday overdrafts: interest-free intraday liquidity against pooled collateral, repayable the same day (BOJ Act, Article 33). Introduced in 2001 to facilitate settlement when BOJ current-account settlement moved to RTGS. Available only in yen during BOJ-NET hours. Ineligible users include insurers, funds such as investment trusts (custodian-bank client accounts), and domestic / foreign financial institutions without BOJ-approved offices and accounts. © Progmat, Inc. #17 English reference translation | Japanese original prevails
19. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #Target market: government-bond repos | Over JPY 2,500tn globally; Japan over JPY 250tn (about 10%) Government-bond-backed repo outstanding was estimated at about USD 16 trillion at end-2024 (JPY 2,560 trillion at JPY 160 / USD), up 20% from 2022. Japan accounts for about 10% of the global total, a relatively strong presence for Japan / yen-denominated assets, making this a target asset class and market of substantial scale. Source: Financial Stability Board, Vulnerabilities in Government Bond-backed Repo Markets (4 February 2026) English reference translation | Japanese original prevails © Progmat, Inc. #18
20. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #JGB repo market trends | Rapid growth since 2022 alongside increased yen investment by nonresidents Japan's outstanding repo transactions have risen since 2010, with rapid growth from 2022. Nonresidents, including hedge funds, have increased yen cash investment as currency conversion became attractive. Domestic investors (banks and trust banks) have increased bond investment, while securities and tanshi companies have expanded intermediation between investor sectors. Chart: Official BOJ English edition (December 2025), Box 2, Chart 3, p. 12. Latest data: end-July 2025. Source: BOJ Financial Markets Department, Trends in the Money Market in Japan, Tokyo Money Market Survey (August 2025). English reference translation | Japanese original prevails © Progmat, Inc. #19
21. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #JGB repo trends | About 60% GC; over 70% of GC is gensaki. 60% centrally cleared; 40% outside CCPs Most repos are GC (general collateral) repos, which are primarily funding transactions without a specified issue. After the full introduction of new gensaki in 2002 and JGB settlement shortening to T+1 in 2018, migration to new gensaki (bond sales / purchases with repurchase / resale conditions) has progressed. Subsequent-allocation GC repos have 40% remains CCPs. helped CCP (JSCC) trades reach 60%12: of Amount the market; Chart Outstanding in outside the Repo Market By Transaction Type By transaction type SC Borrowing Repos Cash Side Cash Lending Side tril. yen 160 tril. yen 300 140 tril. yen 140 250 250 33 124 111 200 107 150 81 60 100 50 0 0 16 17 18 19 20 SC repos 21 22 23 24 GC repos GC = general collateral SC = special collateral 25 0 21 91 67 117 129 25 22 23 24 25 16 Cash 17 borrowing 18 19 side 20 21 80 30 21 22 22 23 24 Cash24lending 23 25 side 200 60 150 40 15 77 30 72 10 165 164 20 29 25 93 100 87 0 20 5 50 10 21 22 23 24 25 21 22 23 24 25 0 Bond lending side Bond borrowing side 0 16 17 18 19 20 21 22 23 24 25 Cash-collateralized securities lending transactions SC repos GC repos Cash-collateralized Not centrallysecurities cleared lending transactions Securities repurchase transactions (prior collateral allocation) Centrally cleared Securities repurchase transactions Ratio of centrally cleared (right-hand scale) Securities repurchase transactions (subsequent collateral allocation) 25 80 20 26 70 60 27 50 30 40 25 106 106 24 59 20 50 30 99 100 40 148 159 % 100 33 100 80 150 tril. yen tril. yen 300 120 44 41 250 120 200 Chart 13: Amount By settlement type Outstanding in the Rep GC Repos Cash Borrowing Side 300 By Contract Type By contract type Note: "Centrally cleared" means transactions cleared by Japan Securities Clearing Corporation (JSCC). Note: "Centrally cleared" refers to transactions cleared by J Charts: official BOJ English edition (December 2025), Chart 12 (p. 25) and Chart 13 (p. 26); matching panels. Source: BOJ Financial Markets Department, Trends in the Money Market in Japan - Tokyo Money Market Survey (August 2025) English reference translation | Japanese original prevails © Progmat, Inc. #20
22. #2 Background and rationale for on-chain finance and tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #JGB repo trends | Securities firms, tanshi firms and others intermediate bilateral trades outside CCP clearing Only clearing members can participate in CCP-cleared trades. Non-cleared trades involve a wider range of sectors; links from non-residents to securities firms are especially important. Securities firms, tanshi firms and others trade with non-clearing financial firms (including life insurers and regional banks), linking them to the CCP network. Many transactions in this segment are decentralized and individually arranged. English reading key (original FSA figures retained) Figure 9 | Inter-sector networks by CCP clearing status Table 6 (left) CCP clearing by reporter and GC / SC repo type. Upper table: GC repos Lower table: SC repos GC = general collateral SC = special collateral Row order in both: 1. Banks 2. Securities firms 3. Tanshi companies 4. Trust banks 5. Life insurers 6. Other financial firms 7. Other Column groups: Left: bond lenders (cash borrowers) Right: bond borrowers (cash lenders) Each group shows: Cleared (JPY tn), Non-cleared (JPY tn), Cleared share (%) As of end-March 2025. Table source: FSA. Figure key: Left = CCP-cleared; right = non-cleared. Nodes: tanshi companies (purple), trust banks (orange), securities firms (light green), life insurers (dark green), non-residents (pink), banks (clearing / non-clearing members), and other. Note: Arrows run from bond recipients (cash lenders) to bond providers (cash borrowers). Line width shows outstanding transaction amounts; circle size shows each sector's PageRank. As of end-March 2025. Source: FSA Institute, The Role of Central Counterparties (CCPs) and Haircuts in Japan's JGB Repo Market (DP2025-8) English reference translation | Japanese original prevails © Progmat, Inc. #21
23. CONFIDENTIAL / Discussion Purpose Only #3 Approaches to tokenizing JGBs © Progmat, Inc. #22 English reference translation | Japanese original prevails
24. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Tokenization methods | On-chain book-entry JGBs offer the comparative advantage Issues Tokenizing book-entry JGBs themselves is more consistent with existing frameworks and processes than registered JGBs. Industry standardization to maximize on-chain benefits and the impact of coexistence with existing securities still need verification. However, legal, tax and operational impacts make the linked-rights model unlikely to be adopted, leaving this effectively the only option. Realizing on-chain benefits Assumes linkage of the JGB register and blockchain; benefits equivalent to corporatebond STs Industry standardization is important for linking transactions across account managers Potentially flexible design (though reliant on the linking entity's credit) Operational impact on market participants Difficult interoperability with book-entry JGBs; dual management and rulemaking burdens Fungibility / collateral value unchanged; impact of coexistence with existing securities needs verification Cannot preserve fungibility / collateral value; unacceptable to existing participants Withholding-tax exemption for financial institutions, etc. excludes registered JGBs (amendment needed) *2 Withholding-tax exemption for financial institutions, etc. covers book-entry JGBs (no amendment needed) Nature differs from bookentry JGBs; withholdingtax exemptions, etc. do not apply (amendment needed) Possible through ministerial ordinance amendments, etc., applying the Act on National Government Bonds Assumes the CSD manages the records; follow the Book-Entry Transfer Act Written perfection required; special treatment under the Industrial Competitiveness Enhancement Act or new law needed Registered JGBs themselves (no certificates: BOJ JGB register) Book-entry JGBs themselves (no certificates: Book-Entry Transfer Act) Rights linked to book-entry JGBs (delivery / conversion claims) Tax-law amendment burden Legal amendment burden *1 *1 "No certificates are issued when JGBs are registered" (Act on National Government Bonds, Art. 2(2)) *2 Act on Special Measures Concerning Taxation, Article 8(1) *2 Tokenization target © Progmat, Inc. #23 English reference translation | Japanese original prevails
25. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Rights linked to book-entry securities | Perfection and fungibility are key issues This model uses tokens representing claims for delivery / conversion for on-chain collateral transactions, limiting effects on the existing JGB Book-Entry Transfer System and its register hierarchy. Book-entry transfers occur only in exceptions such as liquidation. Perfection of ordinary token transfers and fungibility as collateral assets remain issues. [Exception] On-chain tJGB (claim) [Normal] Issue / pledge 01 02 Transfer Repo transaction (execution venue) [Normal] Return 10 [Exception] Claim delivery of linked securities Indirect participant C Lender (nonresident, etc.) 03 Foreign indirect participant E 04 (borrower) (global custodian) JGB Book-Entry Transfer System (Book-Entry Transfer Act) Book-entry register Prop. 00 05 [Exception] Transfer request (financial institution) Book-entry register Indirect participant C Indirect participant D Prop. Prop. [Normal] Held in C's name Prop. Cust. Token transfer leaves the linked securities unmoved; the holder's name is unchanged 09 [Exception] Transfer notice Exercising the right triggers transfer of the linked securities under existing procedures Direct participant A Cust. Book-entry register Represents a claim on linked securities Cust. [Normal] Held in C's name [Exception] Credit balance (sub-custodian) Book-entry register Perfection and fungibility are key issues Cust. CSD (Bank of Japan) 00 06 [Exception] Transfer notice Direct participant B Indirect participant E Indirect participant F Prop. Prop. Cust. Cust. 08 [Exception] Transfer notice Book-entry register Direct participant A Direct participant B Prop. Prop. Cust. 07 Cust. [Exception] Change holder of linked securities (book-entry transfer) Diagram key: Prop. = proprietary account; Cust. = customer account; O = other English reference translation | Japanese original prevails © Progmat, Inc. #24
26. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Book-entry systems | Rights transfer through chained requests / notices and electronic register updates The transferring investor submits a transfer request to its immediate upper-tier institution. Transfer notices are relayed between institutions until they reach the recipient's account manager; debits and credits in each institution's register transfer the rights. The BOJ is the JGB CSD; BOJ-NET (JGB services) and firms' account management systems are the electronic book-entry registers. Book-entry transfer institution (CSD: Central Securities Depository) Account class Type Subcategory Participant [X] (customer) Participant [X] (proprietary) No type name II Prop. I (proprietary) O No type name O No type name O Custody O Prop. I Subcategory II Prop. I No type name O O Custody O Customer [C] Register file Create / retain / inquiries Customer [D] … limits Transfers across different direct participants' customer accounts require CSD linkage (e.g., A → C, D → B) Transfers between a direct participant's proprietary and customer accounts require CSD linkage (e.g., X → Z, Y → C) Book-entry register 10-year retention No type name O No type name O No type name O … O Custody O Prop. I O Prop. I O … II *Input-hour Account mgmt. system O II 10-year retention Messaging Participant / direct acct. mgmt. inst. [Y] Indirect participant [Z] (customer; incl. foreign) Indirect participant [Z] (proprietary; incl. foreign) No type name II O (between accounts / subcategories) Participant / direct acct. mgmt. inst. [X] Type Book-entry register Transfer request / notice Transfer request / notice (between accounts / subcategories) Account class BOJ-NET (JGB services) Participant [Y] (customer) Participant [Y] Register file Create / retain Transfer request / notice (between accounts / subcategories) (Foreign) indirect participant [Z] Account class Type Subcategory Customer [A] Customer [B] Account mgmt. No type name O No type name O … Prop. I O Prop. I O … II Transfer request Investor [A] II Transfer request system … Transfer request Investor [B] Transfer request Investor [C] Investor [D] Diagram key: Prop. = proprietary account; Cust. = customer account; O = other English reference translation | Japanese original prevails © Progmat, Inc. #25
27. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Book-entry systems | Custody-account breakdowns are managed in lower-tier registers The custody account in the CSD's register records aggregate holdings of the direct account manager and customers beneath it; the breakdown is recorded in lower-tier direct / indirect account managers' registers. The Book-Entry Transfer Act does not permit multiple holders' balances to be commingled in one account, but no upper-tier notice is needed if the aggregate custody-account balance is unchanged. Book-entry transfer institution (CSD: Central Securities Depository) Account class Type Subcategory (proprietary) No type name II Prop. I BOJ-NET (JGB services) Book-entry register Participant [X] (customer) Participant [X] O No type name O O Custody O / inquiries Participant / direct acct. mgmt. inst. [X] (e.g., sub-custodian) Type Subcategory Indirect participant [Z] (customer; incl. foreign) Indirect participant [Z] (proprietary; incl. foreign) No type name II Prop. I Customer [D] O No type name O No type name O Custody O Prop. I Transfer request / notice (Foreign) indirect participant [Z] (including global custodian) Type Subcategory Customer [A] Customer [B] Customer [C] … O No type name O No type name O … Prop. I O Prop. I O Prop. I O … Transfer request Investor [A] Customer [E] O No type name O Prop. I II … O … O … II Transfer request II Book-entry register 10-year retention Register file Create / retain Account mgmt. system Registered holder under the Act, but holds underlying investor assets in omnibus custody outside the framework Transfer request Transfer request Investor [B] Investor [C] Underlying investors limits Multiple customers' balances cannot be commingled in a single account Breakdowns of transfers within the same account at a lower-tier account manager are not visible here* *For individual global custodian customer accounts, upper-tier institutions also recognize transfers Global custodian [D] No type name II II *Input-hour Account mgmt. system Transfer request (between accounts / subcategories) Account class Register file Create / retain Messaging Transfer request / notice (between accounts / subcategories) Account class 10-year retention Custody accounts record aggregates, without their breakdown No request, etc. arises if the account and subcategory remain unchanged This institution manages the issue / amount breakdown for customers with accounts at lowertier account managers A global custodian that is not an account management institution may also use omnibus custody (outside the Act; subject to local law) Investor [E] Diagram key: Prop. = proprietary account; Cust. = customer account; O = other English reference translation | Japanese original prevails © Progmat, Inc. #26
28. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only On-chain book-entry securities | OC accounts synchronized with DLT tokens Create on-chain management accounts (OC accounts) linked to DLT records, and switch management to / from existing accounts without changing the securities' book-entry nature. Securities in OC accounts are minted, transferred and burned on DLT as tokenized (t) book-entry securities. The linked OC accounts serve as the electronic records of the bookentry transfer account register. Existing management account (Register for existing book-entry securities) Tokenization (Book-entry transfer of existing securities to an OC account; management switch) On-chain management account (Register for tokenized book-entry securities) Investor [A] customer account (existing) Investor [A] customer account (OC) Security 01: Balance 000 tSecurity 01: Balance 100 [↓]100 ↑ 100 Debit the amount being tokenized Credit the OC-account amount (transfer) Under account manager's node └ Investor [A] ID └ tSecurities: 100 (Mint) Investor [A] customer account (OC) tSecurities transfer tSecurity 01: Balance 050 (Debits / credits to amounts managed in OC accounts) (No change) Detokenization Investor [A] customer account (existing) Investor [A] customer account (OC) Security 01: Balance 030 tSecurity 01: Balance 020 [↑]030 ↓ 030 (Book-entry transfer from an OC account back to an existing management account) Distributed ledger (DLT) Credit the detokenized amount (transfer) ↓ 050 Sync DLT state and debit / credit (transfer) Debit the amount returned to existing management Investor [A] ID → Investor [B] ID └ tSecurities: 50 (Transfer) Under account manager's node └ Investor [A] ID └ tSecurities: 030 (Burn) © Progmat, Inc. #27 English reference translation | Japanese original prevails
29. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only On-chain book-entry securities | CSD linkage is essential to bring all transactions on-chain Each account management institution operates a system for OC accounts. Token transfer information is continuously synchronized over DLT within the necessary parties, satisfying the Book-Entry Transfer Act's request / notice requirements. Horizontal transfers across account managers (or proprietary accounts), rather than vertical transfers, require CSD linkage; several methods are possible. Book-entry transfer institution (CSD: Central Securities Depository) (proprietary) No type name Prop. I II Participant [Y] (customer) Participant [Y] (proprietary) O No type name O No type name O Custody O Prop. I II BOJ-NET (JGB services) Book-entry register (API linkage) O No type name O O Custody O (*1) (DLT linkage) CSD transfer requests / notices may use APIs as well as direct DLT linkage Participant / direct acct. mgmt. inst. [Y] Participant / direct acct. mgmt. inst. [X] Indirect participant [Z] (proprietary; incl. foreign) Existing acct. OC acct. Indirect participant [Z] (customer; incl. foreign) Existing acct. 24/7 operation Customer [C] Existing acct. OC acct. Customer [D] OC acct. Existing acct. acct. [X]DLT linked system mgmt. system (*2) OC acct. Book-entry register (tSecurities) Always synchronized Account transfer (tokenization) *Nature unchanged (Foreign) indirect participant [Z] Customer [A] Meets request / notice requirements under the Book-Entry Transfer Act Account transfer Reversible switch (detokenization) acct. Customer [B] [Z]DLT linked system mgmt. system Existing acct. OC acct. Investor [A] Existing acct. (*2) OC acct. Distributed ledger (DLT) / on-chain Participant [X] (customer) Participant [X] (Existing messaging / inquiries) acct. [Y]DLT linked system Book-entry register mgmt. system (*2) (tSecurities) Always synchronized Several CSD-linkage methods are possible (existing messages, APIs, direct DLT linkage, etc.) Book-entry register (tSecurities) Investor [B] Investor [C] *1 Minimum requirement: 24/7 data updates / notices, even without a DLT node Investor [D] Each investor's wallet (*3) *2 Several options for the authoritative record, depending on technical requirements, etc. Existing acct. = existing management account; OC acct. = on-chain management account English reference translation | Japanese original prevails *3 Key management may be outsourced © Progmat, Inc. #28
30. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Early implementation | Start with on-chain transactions beneath a single direct account manager On-chain transactions beneath a single direct account manager can be implemented early because book-entry transfers can complete without CSD linkage. For example, its proprietary account and investors under other institutions may be able to demonstrate purely vertical on-chain transactions by using a global custodian's account as a lower-tier institution. Book-entry transfer institution (CSD: Central Securities Depository) No type name II O No type name O O Custody O Register file Create / retain *Input-hour / inquiries Participant / direct acct. mgmt. inst. [X] (e.g., sub-custodian) Indirect participant [Z] (customer; incl. foreign) 10-year retention Messaging Only the custody-account breakdown changes; no request / notice is needed Indirect participant [Z] (proprietary; incl. foreign) Node [X] does not synchronize the breakdown of [Z]'s customer account or [D]'s omnibus custody holdings Book-entry register limits Always synchronized Account mgmt. system Customer [E] Customer [D] Existing acct. OC acct. Account transfer OC acct. OC acct. *Nature unchanged (tokenization) Customer [A] OC acct. Investor [A] Existing acct. OC acct. Account transfer Reversible switch (detokenization) (Foreign) indirect participant [Z] (including global custodian) Existing acct. Existing acct. Customer [B] Existing acct. OC acct. Investor [B] *1 Outside the Act; legal status differs from other OC accounts Global custodian [D] Customer [C] Existing acct. OC acct. Investor [C] Existing acct. OC acct. Registered holder under the Act (*1) Underlying investors [X]DLT linked system Register (existing securities) 10-year retention Existing acct. (*2) Register file 24/7 operation Book-entry register (tSecurities) Create / retain Meets request / notice requirements under the Book-Entry Transfer Act Account mgmt. [Z]DLT linked system system (*2) Book-entry register Distributed ledger (DLT) / on-chain (proprietary) Prop. I BOJ-NET (JGB services) Participant [X] (customer) Participant [X] (tSecurities) Investor [E] *2 Several authoritative-record options, subject to technical requirements, etc. Existing acct. = existing management account; OC acct. = on-chain management account English reference translation | Japanese original prevails Each investor's wallet (*3) *3 Key management may be outsourced © Progmat, Inc. #29
31. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only Ledger structure | New-system account records are the authoritative register for tSecurities The authoritative book-entry transfer account register for tSecurities needs DLT linkage and 24/7 operation, favoring the new system's account records. A segregated copy is also synchronized to the existing account management system to minimize impacts on existing operations and ancillary systems. Its operating-hour constraints mean it is not the basis for rights transfers. Existing book-entry securities Account manager's internal systems Authoritative tSecurities book-entry transfer register 24/7 operation / common global standards (Multiple) distributed ledgers (DLT) 24/7 real-time sync New system (DLT-linked) Copy / duplicate of tSecurities balances *2 Data sync (while open) *3 Existing account mgmt. system Equivalent to transfer request / notice ↓ *1 Limited operating hours Tokenized (t) book-entry securities External systems / linked networks [A] OC acct. [B] OC acct. [A] OC acct. ↑ Periodic import while existing SYS is open Book-entry transfer *4 CSD system Limited operating hours Limited operating hours Customers / other account managers Equivalent to book-entry transfer ↓ [A] account [B] account ↑ Results (while open) Settlement matching (PSMS, JASDEC) [B] OC acct. Existing ancillary systems Book-entry register file (10-year retention) Existing account mgmt. system Matching (while open) Data notice (while open) Data received (while open) Authoritative register for existing securities *1 CSD linkage remains to be considered: existing messaging, APIs or direct DLT linkage. *2 DLT itself could be treated as the authoritative record, but names and other ID-linked data should preferably be stored in an off-DLT database; a DLT node alone is insufficient. The main proposal is a technology-neutral relay-hub system, independent of the chosen DLT. *3 Management / implementation must appropriately segregate records. *4 Subject to reflecting account classifications (proprietary / customer / trust), compliance with notice and transfer sequencing under Article 95 of the Book-Entry Transfer Act, and procedures for record corrections under Article 26 of the BOJ Business Regulations, etc. © Progmat, Inc. #30 English reference translation | Japanese original prevails
32. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only System architecture and flows | Issuing tSecurities (switch to on-chain management) The issues and amounts of on-chain tSecurities are managed in OC accounts separate from existing accounts. New-system account records are the authoritative register, synchronized as copies to the existing account management system. Debiting the existing account and crediting the OC account constitutes a book-entry transfer, so the transferrequest data requirements are assumed to be met. The issues / amounts switched to on-chain management as tSecurities require a separate management category so they are not confused with existing off-chain holdings. Two methods are possible: (1) a flag within the same account or (2) separate accounts. Option (2) is more likely to reduce changes to existing systems, so creating new OC accounts is the main proposal. Participant / direct acct. mgmt. inst. [X] (Multiple) DLTs [X] node (tSecurities issuance authority) (multiple IDs managed) [B] Issue tSecurities for specified issue and amount [New] Token mgmt. SYS | Issue / transfer / redeem 02 *2 [A] OC acct. Instruction to switch existing securities (specified issue / amount) to on-chain 01 management Existing account mgmt. SYS Aggregate / manage all account data ↓ 03 ↑ [A] OC acct. Credit OC account*3 Periodic Update Existing ancillary SYS [A] account Latest OC-account balance (copy) Periodic import while open [New] Transfer-link SYS | OC account (auth.); sync existing ledger Acct. Acct. [A] 04 [New] Common registry | Network participant data Debit existing account (while open) Equivalent to book-entry transfer 00 Periodic Create Book-entry register file (retain for 10 years) Existing transfer-request messages coexist (tSecurities are excluded) (Request to issue tSecurities) Equivalent to transfer request *1 Holder [A] is unchanged, but the account type changes tSecurities balance updated Investor [A] 05 *1 Required transfer-request and transfer-notice fields must be included. *2 Must satisfy the Act's book-entry transfer account register requirements. *3 Operations for lags / discrepancies between DLT, authoritative record and copy are set out in a separate table. Diagram key: auth. = authoritative; prop. = proprietary account; cust. = customer account English reference translation | Japanese original prevails © Progmat, Inc. #31
33. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only System architecture and flows | Transferring tSecurities on-chain: one tier After trade execution and DvP on DLT, the new SYS imports the data and updates the authoritative OC-account record, constituting book-entry transfer and establishing legal rights. DLT unlocking / transfer then completes. The existing account management SYS serves as a relay hub for ancillary-system updates to minimize changes. Ledger consistency is checked periodically. *1 Equivalent to a transfer request Participant / direct acct. mgmt. inst. [X] (Multiple) DLTs Data linkage OC-account 04 [X] node (tSecurities issuance authority) (multiple IDs managed) [New] Common registry | Network participant data 06 [New] Token mgmt. SYS | Issue / transfer / redeem [A] [B] Acct. Acct. 03 DLT update 02 (while open) *2 07 ↓ [A] OC acct. [B] OC acct. ↑ Book-entry transfer (legal rights established) 05 Debit [A] OC account → credit [B] OC account Reserve / lock Expire / cancel No acceptance by deadline, or cancellation Both sign Failure Insufficient balance, etc.; retry the same transaction ID Account update Keep locked until book-entry account update completes Unlock No reuse in another transaction while locked Aggregate / manage all account data 09 [A] account 10 Consistency check *3 [A] OC acct. Periodic Update Existing ancillary SYS [B] account Latest OC-account balance (copy) Periodic import while open [New] Transfer-link SYS | OC account (auth.); sync existing ledger Unlock / complete transfer Reserve / lock transfer Data linkage Existing account mgmt. SYS balance sync [B] OC acct. Periodic Create Book-entry register file (retain for 10 years) If only the register file is the authoritative record, each transfer has no effect until the file is created / output. This is impractical: the register as the basis of rights transfers should be distinguished from a means of meeting retention obligations. If only the existing account management SYS is the authoritative record, on-chain activity alone cannot make transfers effective. The existing SYS would also need 24-hour operation and immediate updates, reducing cost / economic feasibility. Use the new SYS as the authoritative record for OC accounts managing tSecurities. Periodically import the latest OC-account balances as copies while the existing SYS is open; it serves as the relay hub for ancillary systems and register files that meet full-record retention obligations. 08 Balance updated Investor [A] 01 Investor [B] Trade executed: transfer tSecurities from [A] to [B] *1 Required transfer-request and transfer-notice fields must be included. *2 Must satisfy the Act's book-entry transfer account register requirements. *3 Operations for lags / discrepancies between DLT, authoritative record and copy are set out in a separate table. Diagram key: auth. = authoritative; prop. = proprietary account; cust. = customer account English reference translation | Japanese original prevails © Progmat, Inc. #32
34. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only System architecture and flows | Transferring tSecurities on-chain: two tiers For a transfer processed through two tiers of account managers, the DLT state is first reflected at the upper tier, then the lower tier, as in the one-tier case. Unlocking / transfer completes only after the full book-entry procedure. Continuous operation can be maintained if each account manager has a new SYS linked to DLT. *1 Equivalent to a transfer request Participant / direct acct. mgmt. inst. [X] (e.g., sub-custodian) (Multiple) DLTs Data linkage OC-account 04 [X] node (tSecurities issuance authority) (multiple IDs managed) [New] Common registry | Network participant data 06 [New] Token mgmt. SYS | Issue / transfer / redeem Data linkage [Z] Cust. *2 03 10 [Z]node *4 (multiple IDs) [B] Acct. Acct. [A] ↓ [Z] OC prop. [Z] OC cust. ↑ Aggregate / manage all account data 12 [Z] prop. 13 Consistency check *3 [Z] OC prop. Equivalent to bookentry transfer Reserve / lock Expire / cancel No acceptance by deadline, or cancellation Both sign Failure Insufficient balance, etc.; retry the same transaction ID Account update Keep locked until book-entry account update completes Unlock No reuse in another transaction while locked Periodic Create [Z] OC cust. Equivalent to transfer notice 05 Debit [Z] OC prop. → credit [Z] OC cust. Data linkage Book-entry register file (retain for 10 years) *1 Indirect participant / account manager [Z] (e.g., global custodian) 07 09 Existing ancillary SYS [Z] cust. Latest OC-account balance (copy) Periodic import while open [New] Transfer-link SYS | OC account (auth.); sync existing ledger Unlock / complete transfer Reserve / lock transfer Prop. [Z] (while open) Periodic Update Existing account mgmt. SYS balance sync ↓ *2 12 ↑ 13 Data linkage *3 Book-entry transfer (legal rights established) 08 Credit [A] OC account DLT update 02 11 Balance updated Proprietary [Z] 01 Investor [B] Trade executed: transfer tSecurities from [Z] to [A] *1 Required transfer-request and transfer-notice fields must be included. *2 Must satisfy the Act's book-entry transfer account register requirements. *3 Operations for lags / discrepancies between DLT, authoritative record and copy are set out in a separate table. *4 Whether a lower-tier institution needs its own node, independent of the upper-tier institution, may depend on the DLT adopted. Diagram key: auth. = authoritative; prop. = proprietary account; cust. = customer account English reference translation | Japanese original prevails © Progmat, Inc. #33
35. #3 Methodology for tokenized JGBs CONFIDENTIAL / Discussion Purpose Only System roles | State discrepancies and approaches to exception handling New SYS (DLT) DvP completed Delay New SYS (DB) Existing account mgmt. SYS Ancillary SYS / files System roles Transfer Consistency check Mismatch detected DvP completed Consistency check Balance updated Re-import Import (after opening / at intervals) Holidays / nights, etc. (closed) Reserve / lock Delay / Incorrect import Same; re-import Update / output (by each deadline) New system (on-chain management) Existing account management system • DLT plus an internal database at the account manager that imports DLT data as needed • Authoritative register for issues managed in existing accounts • Authoritative book-entry transfer account register for tSecurities (on-chain managed issues) • Imports / holds a copy of tSecurities balances; updates ancillary systems and creates / outputs the register file for recording and retaining all holdings DLT: DvP completed (before unlocking) Consistency check Mismatch detected Incorrect import (by each deadline) Holidays / nights, etc. (closed) Failure, etc. Incorrect update Mismatch detected Update / output • Holds no data for issues managed in existing accounts State discrepancies Transfer OC-account balance Latest on-chain managed balance (copy) Not updated Not yet imported DLT: unlocked / transfer completed OC-account balance Latest on-chain managed balance (copy) Updated Delayed / incorrect import DLT: expired / cancelled / failed OC-account balance Latest on-chain managed balance (copy) Incorrect update Incorrect import Correction Same Correction Update / output Proposed approach • A DLT event has not been reflected, or is incorrectly reflected, in the account manager's systems; tSecurities remain locked • Detect with periodic consistency checks, then re-import into the new SYS • The existing SYS holds only a copy; no issue if imported before ancillary-system / file-creation deadlines • Check consistency before the deadline and re-import into the existing SYS • Despite failure, etc. (e.g., insufficient balance), erroneous system updates cause tSecurities state and ownership to diverge • Detect with periodic checks, then correct to match the DLT state © Progmat, Inc. #34 English reference translation | Japanese original prevails
36. CONFIDENTIAL / Discussion Purpose Only #4 On-chain repo: overview and components © Progmat, Inc. #35 English reference translation | Japanese original prevails
37. #4 On-chain repo: overview and components CONFIDENTIAL / Discussion Purpose Only Scope | Post-trade for non-CCP bilateral repo, including intraday and non-residents Fully on-chain trading, including the execution venue, raises many issues and is harder for existing repo participants to adopt. Non-CCP-cleared bilateral trades still involve substantial manual work. Post-trade STP could enable repeatable hourly-tenor trades and ease time-zone constraints in cross-border trades with non-residents. [Execution venue] On-chain channel*1 ▪ Same issues as non-CCP-cleared trades ▪ TokenVault-related entities may also need a financial instruments obligation assumption business license, making near-term delivery unlikely [Post-trade] On-chain*1 [Execution venue] Existing channels [Execution venue] Existing channels *1 TokenVault use, as in existing lending protocols. A TokenVault is a vault-like DLT smartcontract program that holds / controls users’ tokens. □ Existing venues and contracts are retained, preserving convenience and easing adoption □ Scope to improve collateral (substitute securities) management / substitution (may take time) On-chain Existing processes ▪ Legal interpretation of TokenVault use is not yet mature ▪ Already somewhat efficient; relatively little incentive to change processes [Post-trade] [Post-trade]*2 ▪ Fragmenting execution venues reduces convenience for existing participants As-is: not assessed □ Potential to make repos lasting a few hours repeatable operations, 24/7 □ Already somewhat efficient ▪ Manual bilateral processes remain ▪ Some concerns over margin / substitutesecurities deadlines and double posting on substitution (deliver first, receive later) ▪ Low-burden processing of repos lasting a few hours is not sufficiently standardized; time-zone and cutoff constraints remain As-is: not assessed CCP-cleared trades*3 Non-CCP-cleared bilateral repo (e.g. intraday) (Eligible clearing participants only) (Broad market participation, regardless of clearing eligibility) Trades and market participants in scope *2 At least matching and settlement. Whether to include collateral management and default procedures remains unresolved. *3 CCP: Central Counterparty (clearing house) © Progmat, Inc. #36 English reference translation | Japanese original prevails
38. #4 On-chain repo: overview and components CONFIDENTIAL / Discussion Purpose Only Contracts | Add a digital-asset annex to the New Gensaki master agreement / GMRA For close-out netting of non-CCP-cleared trades, keep on-chain and existing repo under the same master agreement so they remain in the same netting set. A digital-asset annex addresses differences arising from digital assets and payment methods. The aim is not to create a new master agreement. Trade types and contract structure [CCP-cleared] Participant A Master agreement + schedule (New Gensaki or GMRA) Clearing participant (Eligibility required) Novation (obligation assumption) Contract approach for on-chain repo Existing master agreement + digital-asset annex*3 Participant B Does not replace the existing master agreement (No fragmentation of netting sets for the same counterparty) Clearing participant (Eligibility required) A standard document to bridge the differences when applying that agreement to digital-asset trades (Separate from DLT “contracts,” i.e. code) JSCC (CCP)*1 [Non-CCP-cleared] Participant A Master agreement + schedule (New Gensaki or GMRA) No clearing eligibility required New Gensaki: Master Agreement for Bond Repurchase Transactions Participant B No clearing eligibility required Contract ② *1 JSCC: Japan Securities Clearing Corporation (CCP: Central Counterparty) Participant A Money-market intermediary Participant B Clearing participant (Eligibility required) Clearing participant No clearing eligibility required JSCC (CCP) GMRA: Global Master Repurchase Agreement • Domestic / overseas market participant ↔ overseas participant • English law; ICMA publishes a reference form * Money-market intermediary (CCP / non-CCP trades)*2 Contract ① • Domestic market participant ↔ domestic market participant • Japanese law; JSDA publishes a reference form *2 The intermediary contracts with each side; neither counterparty is disclosed to the other. A clearing participant uses CCP clearing; a non-participant settles bilaterally through BOJ-NET. Existing anonymous order-book (CLOB) trades assume CCP clearing. *3 The same approach / direction as the Digital Bonds Annex published by ICMA (International Capital Market Association) in April 2026. Source: https://www.icmagroup.org/News/ (出所)https://www.icmagroup.org/News/ English reference translation | Japanese original prevails © Progmat, Inc. #37
39. #4 On-chain repo: overview and components CONFIDENTIAL / Discussion Purpose Only What changes | Keep contracts and execution venues; change matching, settlement and collateral Execution venues remain unchanged and a dedicated annex preserves existing contractual relationships. The changes cover matching and settlement (+ collateral management) for non-CCPcleared trades: 24/7 STP addresses PSMS / BOJ-NET cutoffs and manual bilateral work that impedes hourly-tenor trades. CCP-cleared: existing Non-CCP-cleared: existing Non-CCP-cleared: on-chain New Gensaki master agreement or GMRA + schedule Contract + digital-asset annex Clearing participants (eligible entities) Counterparty Non-clearing participants (no eligibility requirement) Execution venue Voice, chat, email, etc. or electronic trading platform (CLOB / RFQ) Trade booking Existing booking system within each market participant Matching JASDEC Pre-Settlement Matching System (PSMS) Cutoffs apply Email, fax, telephone, etc. Clearing Settlement Margin / collateral provision*1 JSCC assumes obligations Completed between the parties, without a CCP BOJ-NET JGB Services ↔ BOJ-NET Funds Transfer: DvP Margin / substitute securities by cutoff Double posting for substitution (Deliver first, receive later) 24/7 Shared access to the same record (Less duplicate calculation / matching) Cutoffs apply DvP on DLT 24/7 Mark-to-market and margin depend on each contract Collateral DvD on DLT 24/7 *1 Details remain unresolved and require further in-depth consideration. The above is reference information providing an overall view. © Progmat, Inc. #38 English reference translation | Japanese original prevails
40. #4 On-chain repo: overview and components CONFIDENTIAL / Discussion Purpose Only Non-CCP clearing today | Fax / email, PSMS and BOJ-NET for post-trade One current model is the one-touch-through blind method: securities firms, money-market companies or similar intermediaries act as counterparty to both sides, with contracts and settlement between the intermediary and each counterparty (names undisclosed). Matching uses fax / email or JASDEC PSMS; settlement uses BOJ-NET JGB Services / Funds Transfer. Market participant (Cash borrower) New Gensaki master agreement + schedule (Bond sale with repurchase / resale provisions) Market participant (Securities firm / money-market company, etc.) Terms by email / phone, etc. Front office (GC: amount, tenor, repo rate, terms; SC: issue, amount, tenor, repo rate) Bond repo confirmation by fax / email (GC: confirm issue after execution) (GC: amount, tenor, repo rate, terms; SC: issue, amount, tenor, repo rate) Individual transaction statement by fax / email / post Individual transaction statement by fax / email / post (Copy on trade date; original later by post, or may be omitted) Back office * Depending on counterparty: JASDEC matching via PSMS Cutoffs apply Cutoffs apply Net credit exposure statement / delivered-collateral statement BOJ terminal Fax / email. Margin call: issued = former; received = latter [Start-leg settlement date] Borrower Own account Intermediary Own account Lender Own account [DvP] Borrower Current account Lender Current account Back office Net credit exposure statement / delivered-collateral statement Fax / email. Margin call: issued = former; received = latter Cutoffs apply BOJ-NET JGB Services [End-leg settlement date] Borrower Own account [DvP] Intermediary Current account Front office Bond repo confirmation by fax / email (Confirm trade terms promptly after execution) * Depending on counterparty: JASDEC matching via PSMS Market participant (Cash lender) Terms by email / phone, etc. (Confirm trade terms promptly after execution) (Copy on trade date; original later by post, or may be omitted) Back office Front office New Gensaki master agreement + schedule (Bond sale with repurchase / resale provisions) Intermediary Own account [DvP] BOJ-NET Funds Transfer Borrower Current account Intermediary Current account Lender Own account [DvP] Lender Current account Bank of Japan Financial Network System (BOJ-NET) Source: Progmat, based on Central Tanshi, “The Short-Term Money Market Explained in Charts” English reference translation | Japanese original prevails © Progmat, Inc. #39
41. #4 On-chain repo: overview and components CONFIDENTIAL / Discussion Purpose Only Non-CCP on-chain repo | Integration platforms and DLT standards enable hourly processing, 24/7 Standardize repo trading / collateral management on DLT for STP, linked to tSecurities and TD / SC accounts, to execute hourly processing 24/7, including legal transfer. Where multiple standards coexist, a cross-product integration platform connecting existing operations / systems is envisaged to manage on-chain liquidity, collateral and settlement. Participant (borrower) or intermediary Participant (lender) or intermediary New Gensaki master agreement or Global Master Repurchase Agreement + schedule + digital-asset annex Front office Terms via existing methods (Select tSecurities; specify start / end settlement times) Trade results via existing methods Confirm / approve trade Back office Integration platform*1 Terms via existing methods (Select tSecurities; specify start / end settlement times) Integration platform*1 Liquidity management Collateral management Collateral management Settlement management Settlement management 24/7 [Start-leg settlement time] *2 Borrower ID Lender ID (Multiple) DLTs Borrower ID Back office Account updates / report output [End-leg settlement time] tSecurities network Borrower ID TD / SC network Borrower ID [DvP] Lender OC account Confirm / approve trade Liquidity management Acct. mgmt. inst. Front office Trade results via existing methods 24/7 Account updates / report output Borrower OC account Execution venue Deposit institutions, etc. Lender ID Borrower TD / SC acct. Lender ID Lender TD / SC acct. [DvP] Lender ID *1 Where issuers, execution venues and post-trade standards providers each offer vertically integrated products, a mechanism may be needed to connect existing operations / systems across products. *2 OC account = on-chain management account constituting the tSecurities book-entry transfer account register. See the slides on implementation / ledger structure for book-entry transfer × on-chain management for the account-token relationship and legal structure. © Progmat, Inc. #40 English reference translation | Japanese original prevails
42. #4 On-chain repo: overall design and components CONFIDENTIAL / Discussion Purpose Only #On-chain repo system architecture | Issuer nodes, post-trade standards and integration platforms Execution venues and front-office arrangements stay as they are. Integration platforms connect to issuer nodes at account management and deposit-taking institutions, letting participants manage their own tokenized securities / TD / SC and use multiple post-trade standards after repo execution. Links to a future common collateral-management platform are also envisaged. Open an on-chain (OC) account for tokenized securities 00 00 Trading participant A Indirect acct. mgmt. inst. Book-entry account system [New] Common registry 01 01 Execution venue Trading terminal / market GUI Confirmation / management Trade 04 Trading participant B Trade Voice, chat, email, etc. 04 Electronic trading platform Core accounting system Info update 01 Confirmation / management 05 Collateral overview / optimal allocation Various 07 balance updates Various balance 07 updates 09 Core banking system Trading terminal / market GUI Core accounting system 05 Info update 03 Deposit-taking institution, etc. TD / SC issuance request [New] Transfer interface *1 Tokenized securities issuance request [New] Token mgmt. system Open a TD / SC account 03 [New] TD / SC system Direct acct. mgmt. inst. Book-entry account system [New] Common registry [New] Token mgmt. system [New] Transfer interface Issue tSecurities 02 Issuer node tSecurities issuance authority Manage multiple IDs [New] Integration platform [New] Common collateral platform Record trades on DLT Connect multiple protocols Key mgmt. / node access tSecurities balance update 03 07 06 Record trades on DLT Connect multiple protocols Key mgmt. / node access Consolidate collateral data Cross-platform optimization Aggregate 08 data DLT link DLT link 06 07 03 Multiple DLTs TD / SC balance update Repo / collateral standards execution layer Participant ID [A] Participant ID [B] Post-trade processing (no reconciliation) Atomic DvP (simultaneous collateral / cash transfer) Cross-platform collateral management *1 Future implementation may support settlement after switching to an OC account following execution, as well as issuance in advance. [New] Integration platform *2 Participant ID [A] Participant ID [B] 02 Issue TD / SC Issuer node TD / SC issuance authority Manage multiple IDs *2 Future extension area, for example DTCC's Collateral AppChain. © Progmat, Inc. #41 English reference translation | Japanese original prevails
43. CONFIDENTIAL / Discussion Purpose Only #5 Further issues: tokenized JGBs and on-chain repo © Progmat, Inc. #42 English reference translation | Japanese original prevails
44. #5 Further issues: tokenized JGBs and on-chain repo CONFIDENTIAL / Discussion Purpose Only Legal issues for tokenized JGBs Issue Legal nature of tokenized securities in the DTCC precedent (Depository Trust & Clearing Corporation, US securities depository / clearing group) ▼ Background / premises • Identify approaches or implications that could inform the legal characterization of tokenized JGBs (tJGB) under Japanese law. Current WG view ▪ A “Security Entitlement” under Article 8 of the US Uniform Commercial Code (UCC), recorded using DLT (“Tokenized Entitlement”) Remaining issues and direction — None in particular • Does not create a new right : Token records represent existing rights in the DTC (The Depository Trust Company) holding hierarchy. • This characterization cannot be directly transplanted / simply substituted into Japanese law : DTC participant accounts and Japan’s JGB Book-Entry System / book-entry transfer account register differ in hierarchy and rights structure. • Extract the design principles of identity of rights, ledger synchronization and participant management. Legal structure of tJGB under Japanese law ▼ Background / premises • The extent of economic equivalence to JGBs, enforceability of rights, perfection against third parties and validity as collateral is critical to institutional investors’ use in repo markets. • Excessive legal requirements could, however, delay launch. ▪ Treat tJGB as a way to manage / transfer book-entry JGBs themselves, rather than as a claim token • The Book-Entry Transfer Act is technology-neutral regarding electronic records in the book-entry transfer account register (DLT may be used). : Under Article 22(2) of the Bank of Japan Regulations Concerning the JGB Book-Entry System, the BOJ uses BOJ-NET JGB Services and account management institutions use account-management systems to record / update required information. Transfer applications / notifications between institutions are also screen inputs / transmissions to systems that satisfy legal requirements. : A new system incorporating DLT could likewise be a component of each institution’s internal systems: only the electronic recording method differs, so the existing legal characterization can be retained. • Claim-based forms (including trust beneficial interests) do not preserve identity of rights and are unsuitable for repo use. ▪ Before commercialization, confirm with the BOJ and relevant authorities that the specific design is valid in the following respects • Compliance with the Act / BOJ rules : Required recorded items, immediacy, 10-year retention, correction, hierarchical notification, domestic establishment / management entity, etc. • Consistency with BOJ book-entry transfer service hours : Article 3 of those Regulations specifies the hours. Would they constrain 24/7 transfers using the new system? © Progmat, Inc. #43 English reference translation | Japanese original prevails
45. #5 Further issues: tokenized JGBs and on-chain repo CONFIDENTIAL / Discussion Purpose Only Main issues and preferred approach for on-chain book-entry securities Issue Option 1 (preferred / main proposal) How to distinguish tJGB switched to on-chain management ▪ Separate accounts: create an on-chain management account (OC account) ▼ Background / premises • A change in management classification is essential to avoid confusion with existing off-chain holdings. • Existing systems: relatively low impact : Multiple account types can already be opened for the same client. • Design constraint: data must satisfy transfer-application requirements : Debits / credits from an existing account to an OC account constitute a book-entry transfer. Define where the authoritative book-entry transfer account register resides ▪ The new system is authoritative for OC accounts ▼ Background / premises • If it is unclear which ledger data constitutes the basis for changes in rights and is subject to recordkeeping / retention duties, stable trading and settlement will be impaired. Update existing peripheral systems and create book-entry register files for recording / retention ▼ Background / premises • Account data must feed existing peripheral systems (fees, tax calculations, etc.) and the required register files. • Immediacy of rights changes: greatest benefit from 24/7 operation : Leaves open the possibility of treating on-chain data changing in real time 24/7 directly as the basis for changes in rights. • Existing systems: relatively low impact : Rights changes take effect through the new system even when the existing system is closed; extending the latter’s hours is not essential. • Design constraint: must meet requirements for the book-entry transfer account register : BOJ rules also apply to the new system, requiring recording, retention, changes, corrections and domestic keeping. (As today, retention files would be created / exported.) ▪ Route via the existing account-management system (periodically reflect OC account balances) • Existing systems: relatively low impact : Existing routes for peripheral updates / register-file creation remain. Implementation is expected to cover only the synchronization route from the new system. Option 2 (less advantageous) ▪ Set a flag: create an on-chain management flag • Existing systems: relatively high impact : A new data field must be added to existing systems, requiring changes. • Design constraint: relatively few constraints : Only the management method within one account changes; no legal restriction. ▪ Only the existing account-management system (and retention-duty output files) is authoritative • Immediacy of rights changes: 24/7 benefits are easily impaired : Limited by existing-system hours; data differs from actual positions for the delay until on-chain synchronization. • Existing systems: relatively high impact : On-chain processing alone does not effect rights changes; 24-hour operation / immediate updates in the existing system ultimately become essential. • Design constraint: relatively few constraints : The new system is only an external device linked / synchronized to the register, leaving open an interpretation that BOJ rules still apply only to the existing system. ▪ Handle OC account balances in the new system • Existing systems: relatively high impact : Each route from the new system to peripheral systems expands implementation scope. Additional aggregation of existing-account and OCaccount data in register files would still be needed. © Progmat, Inc. #44 English reference translation | Japanese original prevails
46. #5 Further issues: tokenized JGBs and on-chain repo CONFIDENTIAL / Discussion Purpose Only Issues in extending on-chain book-entry securities Issue Near-term on-chain transfers of tJGB across account management institutions ▼ Background / premises • Transfers laterally across institutions, rather than vertically within the hierarchy, require the CSD to participate in the sequence of bookentry transfers. • The timing of on-chain support by the BOJ, the JGB CSD, is uncertain. An earlier feasible method would extend use cases beyond transfers under a particular direct account management institution. Current WG view ▪ Prioritize API connectivity triggered by on-chain lock information • Method ①: API connectivity triggered by on-chain lock information (on-chain-compatible) : On a cross-institution transfer, reserve the transfer / lock the relevant balance on-chain, pass that data to the CSD through an API or similar interface, and unlock / enable the on-chain transfer only after receipt of CSD completion data (reflection in the existing off-chain register). : The lag depends on operating-hour and other constraints of the off-chain link between the CSD and direct account management institutions. : If this method supports 24/7 connectivity, it may achieve the objective without putting the CSD system itself directly on-chain. Remaining issues and direction ▪ First demonstrate transfers under a particular direct account management institution, while engaging with the BOJ on API connectivity to the CSD • Method ②: Clients, including global custodians, hold accounts with multiple institutions and handle cross-institution transfers themselves : Compatible with the current framework and easy to start small. However, multiple accounts, prefunded inventory, instruction cutoffs and fragmented collateral create entry barriers, limiting acceptance to a small set of large clients already holding / operating such accounts. • Method ③: Institutions hold accounts with one another, crediting balances on transfers and settling periodically : Some support this as quick to implement, but structural issues include circular legal hierarchies. • Method ④: Add a layer between the CSD and account management institutions : A common layer (special-purpose intermediate custodian) offers strong connectivity, but requires neutral governance design / operating costs, and has an uncertain implementation timeline; its status as a near-term solution is questionable. : Partial account migration also creates a burden (assuming existing book-entry JGBs continue alongside it under current account-management methods). © Progmat, Inc. #45 English reference translation | Japanese original prevails
47. #5 Further issues: tokenized JGBs and on-chain repo CONFIDENTIAL / Discussion Purpose Only On-chain repo issues (1/3) Issue Scope and value of on-chain repo ▼ Background / premises • Without a use case for tokenized JGBs (tJGB), there is no rationale for putting existing book-entry JGBs on-chain. Current WG view Remaining issues and direction ▪ Retain existing execution venues / master agreements and put post-trade processes onchain to expand non-CCP-cleared bilateral repo (non-residents / intraday), rather than a DeFi-like TokenVault model ▪ Specify where / how much pain remains in existing infrastructure and the degree of improvement • Do not (and cannot) replace CCP obligation assumption, clearing or default management : It remains uncertain whether the interpretation that lending protocols perform collateral disposal (“Liquidation”), rather than obligation assumption / “Clearing,” is valid. TokenVault-related entities may require a financial instruments obligation assumption business license (with a low likelihood of registration). • Large domestic financial institutions already have tools such as BOJ intraday overdrafts. : If value centers only on “borrowing cash for a few hours,” the conclusion will simply be that existing tools suffice. : Identify parties unable to use intraday overdrafts (non-residents, funds in trustee-bank custody accounts, etc.), cross-border trades outside BOJNET operating hours, and spot foreign-currency funding (overdrafts assume yen). Test how far constraints are removed relative to existing nonCCP-cleared bilateral repo processes. • The non-CCP-cleared segment has scope for improvement / expansion : Bilateral trades with non-residents and other participants ineligible for clearing, and constrained by time-zone differences in cross-border trading, offer relatively more room for improvement than CCP-cleared trades. : Removing current constraints through post-trade STP could create added value. • Intraday repo is not the entirety of on-chain repo, but is a useful near-term use case to test : The constraint is not an inability to settle JGBs and cash on the same day. It is the burden of managing, across institutions at specified times, two settlements (start / repurchase) and the intervening contracts, balances, interest and return obligations for a loan lasting a few hours. : When manual processes are fragmented, each stage needs checking, instructions, matching and balance updates. Administrative burdens / waiting times can be large relative to the benefit of short trades. “Able to settle today” therefore differs from “able to continuously offer trades using cash / JGBs for only the required few hours.” : On-chain post-trade links DvP at start / repurchase with record updates and notifications under consistent management, reducing repeated checks, matching and instructions and making hourly repo easier to offer as a standardized operation. © Progmat, Inc. #46 English reference translation | Japanese original prevails
48. #5 Further issues: tokenized JGBs and on-chain repo CONFIDENTIAL / Discussion Purpose Only On-chain repo issues (2/3) Issue How to put repo contracts on-chain ▼ Background / premises • While securing acceptance by existing repo participants, it is desirable to standardize how changes arising from on-chain processing are reflected. Current WG view Remaining issues and direction ▪ Rather than create a new on-chain repo master agreement, add / apply a digitalasset annex to existing contracts, preserving contractual relationships, credit limits and close-out netting ▪ Manage contract-term work (adaptation of ICMA standard annexes and detailed definitions) and smart-contract implementation as separate workstreams, developed in parallel • Creating a new master agreement or replacing an existing one creates separate close-out netting sets : Domestic financial institutions use the New Gensaki master agreement (“Master Agreement for Bond Repurchase Transactions”); cross-border trades use the Global Master Repurchase Agreement (GMRA). : A new master agreement separate from existing contracts would place on-chain and existing repo in different close-out netting sets, causing substantial practical difficulty. • ICMA (International Capital Market Association) has already published standard documents : To apply existing GMRA terms to digital-asset trades, ICMA published a Digital Assets Annex in 2024 and added a Digital Bonds Annex for natively issued digital bonds in 2026. : These do not replace GMRA with another contractual framework. They are standard documents supplementing differences relating to “assets / cash in scope,” “effective transfer / payment,” “return of equivalent assets,” “valuation / margin,” “platform disruption,” “default” and “intraday transactions.” • The specifics of annexes / special terms are essentially set by agreement between the parties / market practice. : Japanese-specific elements, informed by ICMA standard annexes, include tJGB legal classification, discharge through tokenized deposits, the relationship between the book-entry register and DLT records, and returns / outage handling across multiple managing banks and platforms. : The extent of detailed additions is fundamentally for the parties to agree. : Each party checks relevant netting opinions for its counterparty / jurisdiction. • Contractual work (means of legal agreement) is separate from smart contracts (method of processing execution). : Parties may determine legal terms individually, while code implementation on DLT proceeds in parallel. © Progmat, Inc. #47 English reference translation | Japanese original prevails
49. #5 Further issues: tokenized JGBs and on-chain repo CONFIDENTIAL / Discussion Purpose Only On-chain repo issues (3/3) Issue Current WG view Remaining issues and direction Legal structure when trust-based stablecoins (SC) or tokenized deposits (TD) form the cash leg of on-chain repo ▪ Even with SC / TD as the cash leg, maintain repo as a sale of tJGB subject to resale / repurchase. TD is relatively easier to analyze; if SC is deliberately used, envisage retaining yen monetary obligations and using SC transfers to discharge them. ▼ Background / premises • Acceptance by existing repo participants depends significantly on the cash leg’s nature as well as that of tJGB. • Rather than treating trust-based SC as the Purchase Price itself, create Purchase Price / Repurchase Price as yen monetary obligations and use SC as the performance method, preserving continuity with existing repo legal structure. : If SC itself is the consideration exchanged for JGBs, the structure may resemble barter rather than a Civil Code sale, raising doubt whether it qualifies as a “sale of securities subject to repurchase or resale” under the Enforcement Regulation of the Close-out Netting Act. : A relatively stable link to New Gensaki / GMRA would therefore retain yen obligations: sell JGBs for JPY 10 billion and repurchase at maturity for JPY 10 billion plus repo interest, transferring SC worth JPY 10 billion as the means of payment. : Even if SC performance in the nature of payment in kind is agreed in advance, its economic substance may still be viewed as an exchange of SC and JGBs. This does not establish that the Close-out Netting Act will definitely apply. ▪ For SC, distinguish payment settlement from use as margin collateral. Authorities must confirm qualification as a specified financial transaction / collateral transaction under the Close-out Netting Act. • TD has a relatively clear existing legal nature as a deposit claim and is closer than SC to conventional monetary settlement, but cannot be treated as “exactly the same as an ordinary deposit” without specifying issuance / transfer mechanics. : TD digitally records / transfers deposit claims against a bank, so characterization is relatively less problematic than for SC. : Settlement of JGB Purchase Price / Repurchase Price, and potentially margining, may therefore be analyzed similarly to existing deposits. : However, legal finality varies with account-transfer versus token-transfer mechanics, the deposit debtor’s identity, updates to the issuing bank’s books, immediate redeemability for the recipient, and the bank’s freeze / cancellation powers. • A design limiting SC to Purchase Price / Repurchase Price settlement is reasonable. : The Act’s Enforcement Regulation defines collateral transactions as lending / borrowing or depositing money or securities for collateral purposes. It is unclear whether SC, an electronic payment instrument, necessarily falls within “money” or “securities.” : It is also uncertain whether SC is included in “property subject to close-out netting” serving as collateral for post-netting claims. ▪ For TD, go beyond general treatment as a deposit claim and establish conditions for legal discharge at the same moment as the tJGB leg • Finality can vary with the issuing bank and specific book-entry, transfer, redemption and freeze conditions. : Confirm each product’s potential for reversal after DvP: whether the bank’s CoreLedger must update; processing / interoperability for transfer to another bank’s customer; compliance freezes; and cancellation of erroneous transfers. © Progmat, Inc. #48 English reference translation | Japanese original prevails
50. CONFIDENTIAL / Discussion Purpose Only #6 Next steps toward practical implementation of tokenized JGBs © Progmat, Inc. #49 English reference translation | Japanese original prevails
51. #6 Next steps toward practical implementation of tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #Phase 2 hands-on testing | A sandbox to clarify implementation requirements Perspective Purpose and status Phase 1 | Desk-based study (May-September 2026) • Agree on the approach to tokenized JGBs (tJGBs). Consensus favors book-entry JGBs, rather than registered JGBs or linked rights. Provide a sandbox for hands-on testing to clarify requirements and resolve questions before implementation. • Agree on the legal structure, system architecture and flows for book-entry JGBs. The new system managing DLT-synchronized OC accounts must also constitute an authoritative part of the book-entry transfer account register and meet the Act and BOJ regulations. Use the existing account management system as an intermediary hub to minimize changes. Include the data needed for DLT flows to constitute transfer applications and notifications. Check ledger discrepancies periodically and enable correction before relevant cut-off times. • Understand operating repo / collateral platforms. Connect multiple platforms, including overseas systems already in operation. Improve understanding through actual interfaces, processing experience and provider Q&A. • Agree on the assumptions, scope and method for on-chain repo. Main scope: bilateral and intraday trades outside CCP clearing. Do not assume a TokenVault; envisage multiple execution routes. Implement standardized, automated post-trade processes on-chain. Information handling Phase 2 | Hands-on testing (November 2026-March 2027) • Publish general / public-interest findings in a report. Finalize it after WG participants review and approve it. In principle, do not publish firmspecific internal information shared during deliberations. DCC membership confidentiality provisions apply. • Test and refine use-case hypotheses from Phase 1. Let each firm test its proposed uses with minimal individual environment setup, making practical implementation studies more concrete. • Resolve remaining cross-industry issues and legal questions identified during hands-on testing as they arise. Examine existing and new issues raised during testing in parallel. • The testing itself is generally private, limited to participants. Publish an outline and results for their announcement value. Follow each provider's NDA provisions for product information, etc. Participants must agree to separate hands-on testing participation rules. Participants • No restrictions. DCC member firms on the WG participant list, and observers such as the authorities. • Categories reflect the level of participation. Partner providers: multiple domestic / overseas repo and collateral platforms. Sandbox participants: market participants accepting the rules and conditions. Experts / observers: other market participants, law firms, industry bodies, etc. Cost sharing • None. Each firm bears its own workload costs for secretariat operations and WG deliberations. • Sandbox participants using the environment / accessing confidential information bear a share of costs. They contribute to building and operating the Canton Network tJGB / digital-cash issuance and management environment and connections to multiple repo / collateral platforms. The amount depends on participant numbers. © Progmat, Inc. #50 English reference translation | Japanese original prevails
52. #6 Next steps toward practical implementation of tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #Overview of the hands-on testing sandbox The secretariat will provide nodes, applications and a simple UI to issue and manage test tokens for tJGBs and TD / SC on Canton Network (Testnet). Execution venues, standards execution and collateral management will connect multiple providers, so participants can observe test-token behavior in demonstration environments. Open an on-chain (OC) account for tokenized securities 00 00 Trading participant A Indirect acct. mgmt. inst. Book-entry account system [New] Common registry 01 01 Confirmation / management Trade 04 Trading participant B Voice, chat, email, etc. Electronic trading platform Trade 04 Core accounting system Info update 01 Confirmation / management 05 Collateral overview / optimal allocation Various 07 balance updates Various balance 07 updates 09 Core banking system Trading terminal / market GUI Core accounting system 05 Info update 03 Deposit-taking institution, etc. TD / SC issuance request [New] Transfer interface Execution venue Trading terminal / market GUI Tokenized securities issuance request [New] Token mgmt. system Open a TD / SC account 03 [New] TD / SC system Direct acct. mgmt. inst. Book-entry account system [New] Common registry [New] Token mgmt. system [New] Transfer interface Issuer node tSecurities issuance authority Manage multiple IDs 03 07 06 [New] Integration platform [New] Common collateral platform Record trades on DLT Connect multiple protocols Key mgmt. / node access tSecurities balance update Issue tSecurities 02 Key [New] Integration platform Record trades on DLT Connect multiple protocols Key mgmt. / node access Consolidate collateral data Cross-platform optimization DLT link Aggregate 08 data DLT link 06 07 03 DLT = Canton Network Repo-contract / collateral standards execution layer Participant ID [A] Participant ID [B] Post-trade processing (no reconciliation) Atomic DvP (simultaneous collateral / cash transfer) Cross-platform collateral management Participant ID [A] Participant ID [B] Progmat provides the sandbox during testing; multiple alternatives are envisaged for commercial use. TD / SC balance update 02 Issue TD / SC Issuer node TD / SC issuance authority Manage multiple IDs Planned connections to multiple platforms for hands-on testing. © Progmat, Inc. #51 English reference translation | Japanese original prevails
53. #6 Next steps toward practical implementation of tokenized JGBs CONFIDENTIAL / Discussion Purpose Only #Hands-on testing | Environment and information access by participant category The DCC secretariat and partner providers supply testing environments and related confidential information. Providers are generally separated by information barriers. Sandbox participants who agree to conditions, including cost sharing, receive full access to their selected environments and information. Experts / observers receive materials and responses to inquiries through the secretariat. Sandbox (SB) participants Experts / observers Expected to be market / trading participants that do not compete with partner providers Accept participation conditions Hands-on testing (common) Hands-on testing (optional) Q&A; identify issues and requests Consolidate materials / seek views Views (as needed) [DCC secretariat] Contact points and information coordination [DCC secretariat] Common testing environment tJGB issuance / transfer / redemption TD / SC issuance / transfer / redemption Integration / cross-platform management Canton Network Optional (selected by SB participants) Optional (selected by SB participants) Optional (selected by SB participants) Optional (selected by SB participants) [Partner provider 1] Testing environment and information [Partner provider 2] Testing environment and information [Partner provider 3] Testing environment and information [Partner provider 4] Testing environment and information No information sharing between providers (in principle) Participants: partner providers, sandbox participants and experts / observers. No information sharing between providers (in principle) Consolidate information (own information) Consolidate information (prior consent required) No information sharing between providers (in principle) Environment providers: DCC secretariat and partner providers supplying test environments. © Progmat, Inc. #52 English reference translation | Japanese original prevails
54. CONFIDENTIAL / Discussion Purpose Only #Appendix Related information © Progmat, Inc. #53 English reference translation | Japanese original prevails
55. #Appendix CONFIDENTIAL / Discussion Purpose Only #Basis for book-entry tokenization | Documents on the JGB Book-Entry System Rules Concerning the JGB Book-Entry System English reading key Table of contents: general provisions; issuers and participants; transfers; special accounts; pledges; fees. Japanese original retained. Source: Bank of Japan, Japanese rules (original excerpt) Bank of Japan Regulations Concerning the JGB BookEntry System English reading key General provisions; issuers and accounts; book-entry transfer account registers; establishment and recording of the registers. Japanese original retained. Source: Bank of Japan, Japanese regulations (original excerpt) Detailed Rules for Use of BOJ-NET (JGB book-entry procedures) English reading key BOJ-NET online procedures, input and processing windows. The shown extract is dated 1 November 2022. Japanese original retained. Source: Bank of Japan, Japanese BOJ-NET rules (original excerpt) © Progmat, Inc. #54 English reference translation | Japanese original prevails
56. #Appendix CONFIDENTIAL / Discussion Purpose Only #Basis for book-entry tokenization | Analysis under existing laws and rules (1/2) Technology neutrality • Article 91(6) of the Book-Entry Transfer Act, cited in Article 22(2) of the Bank of Japan Regulations Concerning the JGB Book-Entry System, provides that a book-entry transfer account register may be prepared in electronic records, limited to those prescribed by the competent ministerial ordinance. Article 2 of the Order on Book-Entry Transfer of Japanese Government Bonds defines these as information recorded in a file stored on a computer or a file prepared using an electronic recording medium (a medium for electronic records). The technical requirements for an electronic book-entry transfer account register therefore do not exclude DLT. We understand that a new system incorporating DLT may also qualify as an electronic record meeting Article 22(2) of the BOJ Regulations. • Article 2 of that Order was amended on 27 December 2023. It had previously referred to a magnetic disk or another item capable of reliably recording specified information by an equivalent method. As part of reviewing compliance with digital principles, the Working Group of the Digital Extraordinary Administrative Advisory Committee discussed revising legislation to clarify that new recording media and cloud services could be used. The discussion favored technology-neutral provisions that would not exclude blockchain and similar technologies (Digital Agency, 13th Working Group meeting). Article 2 of the Order was also listed as a provision requiring amendment in that process: Roadmap for reviewing analog regulations in light of digital principles / list of provisions specifying recording media such as floppy disks / No. 1935. This background likewise supports the view that a new system incorporating DLT may qualify as an electronic record meeting Article 22(2) of the BOJ Regulations. Requirements for the book-entry transfer account register • The BOJ Regulations require, among other things: (1) proper recording of the required particulars (Article 23); (2) preservation of the register for ten years after preparation (Article 25); and (3) immediate recording of changes and the ability to amend or correct a record immediately when an error becomes apparent (Article 26). When implementing the new system, it is therefore important to verify its ability to provide the required recording, retention, amendment and correction functions. Each account management institution should also perform the necessary risk checks, as it does for existing systems, including system risk, contingency measures for failures, access rights, data authenticity and completeness, and consistency with existing systems. • The BOJ and participants, etc. must keep the book-entry transfer account register at their business office or other office. For the BOJ, participants and indirect participants, this is limited to offices in Japan (Article 22(1) of the BOJ Regulations). We therefore consider that each institution must maintain the new system incorporating DLT at its own business office or other office and treat that system as its authoritative register. © Progmat, Inc. #55 English reference translation | Japanese original prevails
57. #Appendix CONFIDENTIAL / Discussion Purpose Only #Basis for book-entry tokenization | Analysis under existing laws and rules (2/2) Hierarchical applications and notifications • Transfers of book-entry JGBs assume the following hierarchy: (1) the holder submits a transfer application to its account management institution; (2) that institution notifies the book-entry transfer institution; and (3) the latter notifies the receiving account management institution (Article 95 of the Book-Entry Transfer Act). Even when a token moves onchain, the process must be capable of corresponding to the Act's transfer application, inter-institution notifications, and entries or records in the book-entry transfer account register. Alternatively, it may be concluded that non-hierarchical on-chain procedures do not fulfill the statutory transfer procedures, requiring separate off-chain applications and notifications. • The current Act assumes a hierarchy of the book-entry transfer institution and account management institutions, with information distributed unevenly among them. Notifications and increases / decreases are recorded sequentially. Ordinary blockchains may not readily fit that hierarchy or sequential-notification flow. Each blockchain system therefore needs individual examination for compatibility with the Act's transfer process. Characterization of the switch to on-chain management • This depends on how on-chain management is structured. If the same customer has multiple accounts under the Act (a non-tokenized account and a tokenized account), and book-entry JGBs move between them, the movement should be characterized as an account transfer. In contrast, if the account's status under the Act remains unchanged and the only change is an internal electronic-record management method, such as tagging the book-entry securities to be managed on-chain or adding such data fields to the account or account management register, it may be appropriate to conclude that no transfer application or notification is involved. Need for consultation with the authorities • The book-entry transfer institution (the BOJ) appears not to have developed its existing operating regulations on the assumption that DLT would be used in the transfer system. It may therefore introduce new technical requirements if DLT use is envisaged. In practice, implementation should proceed while confirming matters with the transfer institution and, where appropriate, regulatory authorities. • If the new system is to be used as all or part of the authoritative book-entry transfer account register, it would be appropriate, before implementation, to align with the CSD on the system's status as that register, how it meets the operating rules' requirements for recording, retention and correction, and its relationship with existing systems. © Progmat, Inc. #56 English reference translation | Japanese original prevails
58. CONFIDENTIAL / Discussion Purpose Only Disclaimer • This material has been prepared for discussion purposes and is not intended to solicit any particular product or service. No contract is formed solely by this discussion or this material. Accordingly, the Company assumes no legal obligation or liability of any kind. • This material is based on various data and other information considered reliable, but the Company does not warrant its accuracy or completeness. All content reflects only the Company's judgment at the present time. The Company accepts no liability for any loss arising in connection with this material. Matters requiring specialist knowledge should always be confirmed with your own professional advisers, including lawyers, tax advisers and certified public accountants. • This material is the Company's copyrighted work and is protected by copyright law. Quoting, reproducing, forwarding or otherwise using all or any part of this material without the Company's prior approval is prohibited. • Company name: Progmat, Inc. © Progmat, Inc. #57 English reference translation | Japanese original prevails
59. CONFIDENTIAL / Discussion Purpose Only English reference translation | Japanese original prevails