This week’s fintech developments show financial infrastructure moving toward more programmable, AI-assisted, and data-intensive operating models. Wealth managers are responding to clients who independently test advice with AI, while private-market growth is increasing pressure on eligibility, valuation, liquidity, and reporting systems. Carta is connecting AI directly to private-capital records, the SEC has clarified a narrow operational issue for ETF creation baskets, and Project Agorá has tested tokenized cross-border payments with real value. Across these developments, the central challenge is consistent: connecting new interfaces and settlement models to authoritative data, deterministic controls, permissions, and complete audit trails.
Wealth management clients are checking advisor recommendations with AI chatbots
High-net-worth clients are already using ChatGPT, Claude, and other AI chatbots to review portfolio recommendations, tax strategies, and questions they plan to discuss with their advisors. Northern Trust began noticing this behavior approximately 18 months ago, while WE Family Offices is considering using Microsoft Copilot to test its own recommendations and anticipate the questions clients may raise. Firms also highlight the risks of factual errors, incorrect calculations, and the disclosure of confidential information to public AI services.
Source: CNBC — Wealth managers face a new challenger: their clients’ AI chatbots
Why it matters
AI is becoming an independent source of analysis in the client–advisor relationship. High-net-worth clients can now use external tools to compare portfolio recommendations, test assumptions, and prepare detailed questions before meetings. This raises expectations for transparency: firms must be able to show the data, assumptions, methodology, and approvals behind each recommendation.
The shift also exposes weaknesses in wealth managers’ data and service models. Capgemini found that only 17% of HNW clients describe their advisory experience as both personalized and seamless, while 97% of firms still segment clients mainly by asset level. Firms with fragmented client, portfolio, and planning data will struggle to produce consistent AI-supported analysis. (Capgemini)
AI can improve advisor productivity, but only within controlled workflows. Deloitte estimates that advisors spend about 70% of their time on preparation and operational work rather than client relationships. Automating research, portfolio analysis, and meeting preparation can release capacity, but firms must retain human review, model testing, audit records, and controls over confidential data. (Deloitte) FINRA has also made clear that existing requirements for supervision, communications, recordkeeping, and fair dealing continue to apply when firms use GenAI. (FINRA)
What teams should watch
1. Recommendation lineage
It may be worth assessing whether every recommendation can be reconstructed from the exact data and assumptions available at the time. Relevant records may include:
- portfolio and household snapshots;
- client objectives, constraints, and IPS rules;
- market, tax, and planning assumptions;
- source documents and market-data timestamps;
- calculation-engine and model versions;
- generated output, advisor edits, and approvals.
The practical test is whether the firm could reproduce the recommendation exactly as it was presented to the client.
2. A controlled AI gateway
Firms may need to consider whether all model traffic should pass through a centralized control layer covering:
- SSO and role-based access;
- PII and account-data detection;
- redaction or tokenization;
- approved model and provider routing;
- prompt and response logging;
- retention and deletion rules;
- rate limits and cost controls;
- provider shutdown and fallback mechanisms.
This becomes particularly relevant where employees may otherwise use public models with confidential client data.
3. Grounding AI in internal data
A key design question is whether advisor tools should rely on unrestricted model output or on retrieval from controlled internal sources, including:
- portfolio accounting;
- CRM and household records;
- financial-planning systems;
- investment research;
- product documentation;
- compliance policies;
- approved tax and estate-planning content.
It may also be useful to require source citations, data timestamps, and indicators of missing or incomplete information.
4. Separation between analysis and action
CTOs may want to define clear technical boundaries between:
- Explain: summarize existing information.
- Analyze: calculate scenarios.
- Recommend: prepare a proposal for advisor review.
- Execute: initiate a transaction after approval.
Each level may require different permissions, audit records, review steps, and confirmation controls.
5. AI evaluation and regression testing
It is worth considering how model quality will be tested after changes to prompts, models, data sources, or retrieval logic. Test coverage may include:
- portfolio and tax calculations;
- source attribution;
- stale or conflicting data;
- unsupported claims;
- client-restriction violations;
- prompt injection;
- restricted-data leakage;
- refusal and escalation behavior.
The evaluation results may need to be linked to each deployed model and prompt version.
6. A canonical client data model
Another question is whether the firm has consistent entities for:
- individuals;
- households;
- trusts and legal entities;
- accounts;
- holdings and tax lots;
- liabilities;
- objectives;
- restrictions;
- consent.
The main technical challenge is resolving these entities across custodians, CRM, planning, and reporting systems while preserving permissions, lineage, and reconciliation status.
Advisor-intermediated private-market assets could grow by another $2 trillion
Cerulli estimates that U.S. clients currently hold approximately $2.2 trillion in less-liquid private-market products through financial advisors and projects an additional $2 trillion in growth over the next five years. The main drivers include the expansion of interval funds and other semi-liquid structures, the incorporation of alternatives into asset-allocation models, and demand for income-generating investments. Scaling the market will require partnerships among private capital managers, traditional asset managers, wealth platforms, turnkey asset management programs, trust companies, and recordkeepers.
Sources: Pensions & Investments · Cerulli Associates
Why it matters
Private markets are moving from a specialist UHNW offering into a broader wealth-management product category. Cerulli estimates that advisor-intermediated private-market assets could increase by another $2 trillion over five years, driven by semi-liquid vehicles, model portfolios, and demand for income-producing investments. (Cerulli)
For wealth managers, this creates an asset-gathering opportunity but also a significant operating burden. In a separate Cerulli study, 81% of advisors said private-market offerings help differentiate their practices, while 67% linked them to HNW client acquisition and 66% to asset retention. However, 56% identified limited liquidity as a barrier, 44% cited client education, and 39% pointed to product complexity and due diligence. (Cerulli)
These products require capabilities that traditional public-market platforms often lack: eligibility controls, digital subscriptions, capital-call tracking, irregular valuations, liquidity monitoring, and consolidated reporting. Regulatory scrutiny is also increasing. The SEC is examining valuation and investor transparency as private-market access expands, while FINRA expects firms to document due diligence, verify material issuer claims, manage conflicts, and disclose liquidity restrictions. (SEC) (FINRA)
What teams should watch
1. A private-assets product model
A traditional security master may not capture enough information for private-market products. Firms may need structured data for:
- legal vehicle and strategy;
- investor eligibility;
- minimum commitment;
- subscription and closing dates;
- lock-up and notice periods;
- repurchase frequency, gates, and limits;
- valuation methodology and frequency;
- capital-call and distribution rules;
- management fees, carry, and waterfalls;
- tax forms and jurisdictional restrictions.
Versioning may be important because product terms can change over time.
2. Rules-based eligibility and suitability
It may be worth reviewing whether eligibility decisions still depend on manual checklists or application code. A dedicated rules layer could evaluate:
- accredited-investor and qualified-client status;
- jurisdiction and account type;
- IPS restrictions;
- concentration limits;
- liquidity requirements;
- investment horizon;
- minimum commitment;
- existing illiquid exposure;
- unfunded commitments.
The output should ideally show the rule applied, the input used, the result, and any required approval.
3. Subscription workflow architecture
Private-market subscriptions often span multiple systems and teams. Firms may want to assess whether the process can be represented as one managed workflow covering:
- product selection;
- eligibility checks;
- KYC and AML;
- accreditation verification;
- document generation;
- electronic signatures;
- funding instructions;
- transfer-agent submission;
- exception resolution;
- custodian and accounting reconciliation.
A single state model may be more reliable than separate statuses in CRM, email, and operations tools.
4. Private-asset valuation data
A dedicated valuation model may be needed to distinguish:
- valuation date;
- receipt date;
- effective date;
- data source;
- estimated or final status;
- manager-reported or independently validated status;
- currency;
- revision history;
- stale-data status.
Historical values may need to remain immutable, with performance recalculated when a prior NAV is revised.
5. Commitments and liquidity as core data
CTOs may want to consider whether commitments and liquidity are treated as first-class portfolio data. Relevant fields include:
- total commitment;
- funded and unfunded amounts;
- expected capital calls;
- distributions;
- lock-up expiry;
- repurchase windows;
- redemption requests;
- gates and prorating;
- available household liquidity.
These data may need to feed portfolio construction, cash forecasting, concentration controls, and reporting.
6. Private-market performance calculations
Standard public-market return calculations may not be sufficient. Platforms may need to support:
- IRR and XIRR;
- multiple on invested capital;
- distributed-to-paid-in capital;
- residual value to paid-in capital;
- total value to paid-in capital;
- realized and unrealized gains;
- performance by vintage, strategy, manager, and vehicle.
The underlying cash flows and valuation inputs should remain available for audit and recalculation.
7. Integration with external parties
A common integration layer may be worth considering for managers, administrators, custodians, and transfer agents. It may need to support:
- APIs and webhooks;
- SFTP and structured files;
- PDF document extraction;
- schema validation;
- idempotent processing;
- duplicate detection;
- reconciliation queues;
- retry and exception handling.
The main objective would be to convert partner-specific formats into one internal event and data model.
8. Digital due diligence records
Firms may want to assess whether product due diligence is stored as a structured, versioned record rather than as emails and shared-drive files. Relevant content includes:
- offering documents;
- questionnaires;
- financial statements;
- legal and compliance reviews;
- valuation and liquidity analysis;
- conflicts;
- red flags;
- approved client segments;
- conditions and expiry dates;
- reviewers and decisions.
Linking the approved product version to each recommendation and subscription may improve traceability.
9. Operational scalability metrics
Before volumes increase, it may be useful to monitor:
- subscription completion time;
- manual touches per application;
- exception rate;
- failed or delayed funding;
- reconciliation breaks;
- stale valuations;
- missed capital-call or repurchase events;
- reporting latency;
- servicing cost per position.
These metrics can show where a process that works for a small UHNW book may fail at larger scale.
Carta launches three Claude plugins for private capital operations
Carta has launched three Claude plugins that connect its system of record directly to an AI workspace. Carta Investors provides access to fund performance, NAV, LP data, portfolio financials, and regulatory reporting; Carta CRMsupports read and write operations across investors, companies, contacts, deals, and notes; and Carta Cap Table covers ownership, SAFEs, option grants, valuations, and waterfall scenarios. Authentication uses OAuth, while financial calculations remain in Carta’s deterministic engines rather than being generated by the language model.
Sources: The Drawdown · Carta
Why it matters
The release moves generative AI from document drafting into live private-capital workflows. Claude can query reconciled fund and cap-table data, run approved Carta tools, and produce Excel reports, presentations, and investor materials without repeated CSV exports and manual formula rebuilding. Carta reports that one early customer reduced reconciliation work across four funds and 100 SPVs from one week to one day, although this is a customer testimonial rather than an independently verified benchmark.
The architecture is more significant than the chatbot interface. Carta keeps payouts, waterfalls, vesting schedules, and journal entries in deterministic calculation tools, while Claude handles natural-language requests, orchestration, analysis, and document assembly. This provides a practical model for financial AI: the language model interprets intent, but the system of record remains responsible for authoritative data and calculations.
It also expands the control surface. The Investors and Cap Table plugins are read-only, but the CRM plugin can create and update records. Carta states that access follows existing user permissions and that financial data passes through Anthropic’s infrastructure. MCP connections also introduce risks including prompt injection, malicious tool instructions, excessive permissions, and unauthorized actions, making connector governance as important as model governance.
What teams should watch
1. The boundary between the model and the financial engine
It may be useful to define which operations can be handled by the language model and which must remain deterministic. NAV, waterfall, allocation, vesting, journal-entry, and performance calculations may need to run in governed services, with the model limited to selecting tools, supplying validated parameters, and explaining results.
2. Read and write permissions at tool level
Existing application permissions may become more consequential when an AI agent can invoke them programmatically. Firms may want to review:
- OAuth scopes assigned to each plugin;
- user, fund, entity, and record-level permissions;
- separation between read and write tools;
- whether bulk access is possible;
- approval requirements for CRM changes;
- token expiry and revocation behavior.
The CRM plugin can create and update records, while the Investors and Cap Table plugins are documented as read-only.
3. Centralized MCP and plugin governance
A controlled connector layer may be preferable to individual plugin installation. Relevant controls could include:
- an allow-list of approved MCP servers and plugins;
- organization-level installation;
- version pinning and update review;
- plugin-source verification;
- outbound network restrictions;
- centralized connector revocation;
- inventory of users, plugins, tools, and scopes.
Carta supports organization-wide administration, but also permits personal and GitHub-based installation paths, which may need separate policy treatment.
4. Protection against indirect prompt injection
The risk is not limited to malicious user prompts. The CRM plugin can research websites and use external content to enrich records. A compromised page, document, note, or attachment could contain instructions intended to influence the model’s tool calls.
Possible controls include:
- treating retrieved content as data rather than instructions;
- limiting tools available during external research;
- validating tool parameters against strict schemas;
- blocking external content from initiating write actions;
- requiring confirmation when retrieved content changes system records.
OWASP identifies prompt injection, tool poisoning, and command execution from untrusted inputs as specific MCP risks.
5. Approval controls for writes and external outputs
It may be worth distinguishing low-risk analysis from actions that change records or create externally distributed materials. CRM updates, LP communications, board materials, and regulatory reports may require:
- a preview of the proposed change;
- field-level diffs;
- explicit user confirmation;
- maker-checker approval for sensitive actions;
- idempotency keys;
- rollback or correction workflows;
- restrictions on automated sending or filing.
6. End-to-end audit records
Application logs alone may not reconstruct an AI-assisted workflow. A complete record may need to capture:
- user and organization identity;
- prompt and conversation reference;
- model, plugin, and skill versions;
- tools called and parameters supplied;
- source records and data timestamps;
- calculation results;
- generated files;
- user edits and approvals;
- final write operations.
This would make it possible to reproduce how an LP report, waterfall scenario, CRM update, or board presentation was produced.
7. Data retention and third-party processing
Carta explicitly states that financial data flows through Claude. Firms may therefore want to verify which Claude product and deployment path is being used, where conversations and artifacts are stored, how long they are retained, and whether deletion settings meet internal policy. Anthropic’s retention arrangements differ between chat products, APIs, and enterprise configurations; custom Enterprise retention has a minimum period of 30 days, while zero-data-retention arrangements apply only to specific eligible products and agreements.
8. Financial-output regression testing
Before relying on plugins in recurring workflows, firms may want reference test sets covering:
- NAV and performance metrics;
- waterfall and conversion scenarios;
- rounding and currency handling;
- fund and SPV boundaries;
- stale or revised source data;
- missing records;
- permission-restricted entities;
- Excel and presentation outputs.
Results could be compared with approved Carta reports and linked to each model, plugin, and skill version.
9. Portability beyond one AI interface
Carta exposes its tools through MCP and supports Claude Desktop, Claude Code, and other compatible clients. Firms may want an internal abstraction between operational workflows and the selected AI interface, so that permissions, logging, evaluation, and business rules do not depend entirely on one model provider or desktop application.
SEC gives ETFs limited relief for creation baskets during passive concentration breaches
On July 27, 2026, SEC staff issued a no-action letter allowing an ETF that has passively exceeded its disclosed industry concentration limit because of market movements to continue accepting certain creation baskets. The relief covers pro rata baskets, cash-in-lieu purchases up to the pro rata amount, and non-pro rata baskets that do not give the affected industry a higher weight than a pro rata basket. It applies to both index-based and actively managed ETFs.
Sources: SEC staff no-action letter and the Ropes & Gray analysis syndicated by JD Supra.
Why it matters
An ETF may exceed its disclosed 25% industry concentration threshold because securities in one sector appreciate faster than the rest of the portfolio. Existing guidance allowed a fund to retain a market-driven excess but created uncertainty over whether accepting a new creation basket containing securities from that industry would constitute an additional investment in breach of its policy.
The letter removes that uncertainty for three defined basket scenarios. ETFs can continue routine creation activity without altering basket composition, substituting assets, or seeking shareholder approval solely because market movements caused the breach. This reduces the risk of operational disruption and avoids changes that could increase transaction costs or disadvantage existing shareholders.
The impact is relevant across a US ETF market comprising 4,495 funds and $13.4 trillion in assets at the end of 2025. However, the letter is a narrow, fact-specific staff position rather than a rule change. Reliance therefore depends on proving that the exceedance was passive and that the accepted basket remained within the conditions described in the letter.
What teams should watch
1. Classifying the concentration breach
It may be worth assessing whether the compliance platform can distinguish a passive exceedance from one caused by portfolio-management activity. The evidence may need to include:
- the concentration level before and after the market movement;
- security prices and industry classifications used;
- trades, corporate actions, and index events during the period;
- the time the threshold was crossed;
- confirmation that the adviser did not actively increase the industry allocation.
The classification may need to remain linked to every creation order processed while the exceedance continues.
2. A pro rata basket benchmark
The three permitted scenarios depend on comparison with a pro rata creation basket. Firms may therefore need a reproducible benchmark containing:
- portfolio holdings and weights at the relevant calculation time;
- industry weights;
- creation-unit quantities;
- rounding and cash-balancing rules;
- excluded or restricted securities;
- the market-data and classification versions used.
The system should be able to reconstruct the benchmark after the trading day.
3. Pre-acceptance basket validation
It may be useful to test every creation basket against the relief before acceptance:
- Pro rata basket: does it approximately reflect the portfolio?
- Cash-in-lieu: is the purchase of the affected security capped at the corresponding pro rata amount?
- Non-pro rata basket: is the affected industry’s weight no higher than in the pro rata benchmark?
A basket outside these conditions may need to enter an exception workflow rather than being processed automatically.
4. Versioned concentration rules
Concentration monitoring may need to account for more than a fixed 25% threshold. Relevant configuration could include:
- the policy disclosed by each fund;
- industry or group-of-industries definitions;
- classification provider and taxonomy version;
- treatment of derivatives and look-through exposures;
- effective dates of prospectus changes;
- fund-specific calculation methodology;
- active and passive breach status.
Keeping these rules outside hardcoded application logic may make policy changes and historical reconstruction easier.
5. Coordination across operational systems
CTOs may want to review whether the same breach status and basket rules reach:
- portfolio-compliance systems;
- basket-construction engines;
- authorized-participant workflows;
- order-management and trading systems;
- fund accounting;
- regulatory and board reporting.
A mismatch between systems could result in a basket being approved under different data, thresholds, or industry classifications.
6. Audit evidence for each creation
A complete record may need to retain:
- the creation order and basket received;
- the corresponding pro rata benchmark;
- pre- and post-creation industry weights;
- cash-in-lieu amounts and subsequent purchases;
- validation results and exceptions;
- approvals and overrides;
- data and rule versions;
- processing timestamps.
Rule 6c-11 already requires written basket policies and procedures, including detailed controls for custom baskets. The no-action letter adds another fact-dependent decision that may need to be evidenced during compliance reviews.
7. Controls around non-pro rata and custom baskets
The relief does not permit any non-pro rata basket during a passive exceedance. The relevant industry weight must remain consistent with the pro rata basket. Firms may want to consider:
- hard limits on the affected industry weight;
- secondary review for custom baskets;
- controls over manual component changes;
- comparison before and after rounding;
- alerts when substitutions change industry exposure;
- documented reasons for deviations.
8. Testing market and data edge cases
Test scenarios may need to cover:
- threshold crossings caused by intraday or closing prices;
- stale or corrected market data;
- industry reclassifications;
- corporate actions;
- index rebalances;
- restricted securities requiring cash substitution;
- rounding that moves the basket above the permitted weight;
- simultaneous breaches across several industries;
- revised portfolio positions received after a basket was accepted.
The main technical question is whether the platform can prove, for each creation, that the breach was passive and that the basket did not increase the shareholder’s proportional exposure beyond the permitted conditions.
Project Agorá completes real-value testing of tokenized cross-border payments
Twenty-eight financial institutions and central banks completed approximately CHF 800,000 in real-value transactions through Project Agorá using tokenized central bank reserves and commercial bank deposits. The tests covered six currencies and 17 scenarios, including corporate and interbank payments, dual-currency transactions, payment-versus-payment settlement, and intragroup transfers. Average settlement time was approximately 80 seconds, despite the prototype not being directly integrated with participating institutions’ production core banking and RTGS systems.
Sources: CoinDesk and the Bank for International Settlements.
Why it matters
The test moves tokenized bank money beyond simulated transactions. Tokens represented real central bank reserves and commercial bank deposits, while payments were processed under realistic operational, compliance, risk, and legal conditions. Approximately 250 public- and private-sector employees participated.
The architecture combines tokenized deposits with settlement in tokenized central bank money on a shared platform. Atomic settlement allows all linked balance updates to complete together or not at all, reducing principal and settlement risk in cross-border and FX transactions. Participants also gained shared visibility into payment status and routing, addressing a persistent weakness of correspondent banking.
The project does not assume that banks will replace their existing infrastructure immediately. Test transactions interacted with core banking and RTGS systems through ISO 20022 messages, including pacs.008, pacs.009, and camt.053. This suggests that adoption may depend less on replacing core systems and more on building reliable orchestration, reconciliation, compliance, and liquidity controls between traditional and tokenized ledgers.
What teams should watch
1. The integration boundary with existing payment systems
It may be useful to assess whether current payment architecture can connect to a tokenized settlement layer without duplicating business logic across platforms. Relevant integration points could include:
- payment initiation through pacs.008 and pacs.009;
- balance and transaction reporting through camt.053;
- RTGS funding and redemption instructions;
- core-ledger postings and funds earmarking;
- payment status and exception events;
- foreign-exchange confirmation.
The main design question is which system remains authoritative at each stage of the payment lifecycle.
2. Token issuance and redemption controls
In the test, commercial banks issued tokenized deposits after earmarking or booking corresponding funds in their core systems. Central banks issued tokenized reserves after receiving funds through RTGS arrangements.
Firms may want to consider how they would maintain:
- one-to-one backing between tokens and underlying balances;
- atomic or tightly controlled issuance and booking;
- intraday reconciliation between core and token ledgers;
- controls against duplicate issuance;
- redemption queues and failed-redemption handling;
- evidence that underlying funds remain restricted.
3. A common transaction state model
A cross-border payment may move through core banking, sanctions screening, FX, RTGS, token issuance, shared-ledger settlement, and reporting. A common state model could help prevent each system from maintaining a different version of the transaction.
Relevant states may include:
- received;
- validated;
- compliance approved;
- funded;
- tokens issued;
- settlement pending;
- settled;
- redeemed;
- rejected or reversed.
Global transaction identifiers, idempotency controls, and timestamps may be needed to connect these states across platforms.
4. Atomic settlement and failure handling
Atomic settlement removes the risk that one leg completes while another fails, but it also creates technical dependencies between all transaction components.
It may be worth assessing:
- timeout and cancellation rules;
- insufficient-liquidity scenarios;
- unavailable counterparties or jurisdictional ledgers;
- failed smart-contract execution;
- partial infrastructure outages;
- recovery after an uncertain transaction state;
- whether failed transactions are rolled back or held for intervention.
The transaction engine may need to guarantee that retries cannot produce duplicate transfers.
5. Liquidity across currencies and ledgers
Tokenized settlement changes where and when liquidity must be available. Firms may need visibility into:
- tokenized reserve balances by jurisdiction;
- commercial deposit-token balances by currency;
- pending payment obligations;
- issuance and redemption requirements;
- payment-versus-payment funding;
- intraday liquidity buffers;
- trapped or idle liquidity across ledgers.
Project Agorá identified liquidity-saving mechanisms as an area requiring further work before scaled deployment.
6. Compliance before settlement
During the real-value test, payment instructions were submitted only after participating institutions completed compliance checks. Some dual-currency transactions also required manual confirmation of the corresponding FX amount.
CTOs may want to consider how AML, sanctions, fraud, and jurisdiction-specific policy checks would operate in a programmable workflow:
- which institution performs each check;
- what data can be shared;
- how screening results are attached to the transaction;
- how long an approval remains valid;
- what happens when sanctions lists or customer data change;
- whether policy rules can block settlement automatically.
7. Privacy across jurisdictions
The prototype uses a shared unifying layer for tokenized commercial bank deposits and separate jurisdictional ledgers for tokenized central bank reserves. Its design also includes privacy controls at token and transaction levels.
This raises architecture questions around:
- data residency;
- participant-level visibility;
- segregation of customer and transaction data;
- sharing information with regulators and central banks;
- encryption and confidential execution;
- retention and deletion requirements;
- investigation access without exposing data to unrelated participants.
8. End-to-end observability
Participants highlighted visibility into payment status and routing as a practical benefit of the prototype.
A production platform may need to expose:
- the current transaction state;
- the institution or component holding the payment;
- completed compliance and funding steps;
- ledger confirmations;
- processing and settlement timestamps;
- failure codes and remediation ownership;
- the final settlement reference.
This information may need to be available to operations, treasury, compliance, counterparties, and corporate clients through different permissioned views.
9. Operational resilience and key management
A shared programmable platform introduces dependencies that differ from traditional messaging infrastructure. Firms may want to assess:
- signing-key custody and HSM integration;
- transaction authorization policies;
- smart-contract deployment controls;
- node and network availability;
- disaster recovery across jurisdictions;
- cyber incident containment;
- degraded-mode processing;
- recovery when the token platform or a connected RTGS system is unavailable.
The BIS identified cybersecurity, operational resilience, interoperability, and governance as areas requiring additional development.
10. Readiness for continuous operation
The real-value test used predefined intraday transaction windows and a coordinated runbook. A production service supporting always-on payments would require a different operating model.
It may be useful to review whether treasury, compliance, support, liquidity management, and incident response can operate outside existing market and RTGS hours. The technology may support continuous settlement before the surrounding organization is ready to manage it.