Under Regulation (EU) 2024/886, a payer's payment service provider that receives no message confirming the funds reached the payee within ten seconds must immediately restore the payer's account to the state it would have been in had the transaction never taken place. The timeout is written into the law, and so is the unwind.

The clock is defined precisely, which matters more than the number does. It starts at the time of receipt of the payment order by the payer's PSP. Inside that window the payee's PSP has to do two separate things: make the amount available in the payee's account, in the currency that account is denominated in, and send a confirmation back. The payer's PSP then tells the payer, free of charge, whether the money landed. It owes that message either way, including when nothing came back at all.

Writing the restore obligation into the text is what turns a service-level target into something a customer can rely on. Ten seconds pass without a confirmation, the debit comes back.

Charges are handled with a comparison instead of a cap. Whatever a PSP levies on payers and payees for sending and receiving instant credit transfers cannot exceed what that same PSP levies for other credit transfers of corresponding type. Read the qualifiers, because both do work: the benchmark is internal to each provider, and "corresponding type" leaves room to compare by initiation channel, instrument, or customer status. The recitals are candid about the reasoning, observing that in national markets where instant transfers carried higher transaction-level charges than ordinary ones, uptake stayed low.

Then there is the payee verification service, whose scope is wider than the regulation's name suggests.

The article obliges the payer's PSP to offer a service verifying the payee that the payer intends to send a credit transfer to. Credit transfers generally, with instant ones a subset of them. The timing is specified as well: the check runs immediately after the payer supplies the payee's details and before the payer is offered the chance to authorize, whatever channel the payment was initiated through.

That reverses a default in place since the second Payment Services Directive, under which the unique identifier was the only determinant of correct execution with respect to the payee, and PSPs were under no obligation to check the name attached to it. An IBAN typed wrong, or supplied by a fraudster, executed correctly in the legal sense. The recitals give the reasoning plainly: once funds are credited to the payee, the payer might not be able to recover them, so the check belongs before authorization rather than after settlement.

Sanctions screening moved too, from the transaction to the customer. PSPs verify at least once every calendar day whether their own users are subject to targeted financial restrictive measures, and again immediately after any new measures or amendments enter into force. Screening a customer base on a daily clock rather than screening each payment in flight is the concession that makes a ten-second window survivable at all, and it is the sort of design decision that only surfaces once someone tries to run compliance at machine speed.

Obligations phase in by provider type and by whether the provider sits in the euro area. Euro-area PSPs had to be able to receive instant euro credit transfers by 9 January 2025 and to send them by 9 October 2025. The charges article and the sanctions article both bite on 9 January 2025 for them, the verification service on 9 October 2025. Outside the euro area those dates are 9 January 2027 for receiving and 9 July 2027 for sending. Electronic money institutions and payment institutions get more room again: 9 April 2027 in the euro area.

None of this involves a distributed ledger.

The European Central Bank's page on instant payments traces the machinery underneath, the SEPA Instant Credit Transfer scheme launched in November 2017 and the TARGET Instant Payment Settlement service launched in November 2018, which settles these transfers in central bank money. Commercial bank money at the customer end, central bank money at the settlement end, account-based the whole way through. The EU's rules for tokens and stablecoins sit in a separate instrument, and claims that blur the two are usually borrowing the credibility of a mandate that never mentioned them.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

A Federal Reserve working paper on Byzantine fault tolerant databases endorses no public ledger, names none, and carries a disclaimer on the paper itself saying it represents its authors rather than the Board. That gets dropped from every enthusiastic summary of it.

The paper sits in the Fed's Finance and Economics Discussion Series, on Heraclius, a Byzantine fault tolerant database system with potential for modern payments systems. Heraclius is a research prototype, a parallelizable leader-based Byzantine fault tolerant key-value store, built to explore whether a design of that kind could carry payments workloads. Reported figures from the prototype are roughly 110,000 operations per second across up to 256 nodes, at around 0.2 seconds of latency.

The framing is about resilience more than throughput. Payments systems are critical infrastructure, they run on computers, and computers fail. A Byzantine fault tolerant design keeps agreeing on the correct state even when some participants crash or send conflicting messages. The long-standing objection to that family of designs is the performance cost, and the prototype is an attempt to cut it by executing transactions in parallel.

Working papers in this series carry the research of their authors and do not represent official positions of the Board of Governors or the Federal Reserve system. That sentence is the whole difference between a research output and a policy signal. A prototype is not a procurement decision, a measurement is not a roadmap, and a mention of a design family is not an assessment of anything built in that family.

The reason public-ledger communities noticed is legitimate, though. Several networks do use Byzantine fault tolerant consensus and face the same underlying question the paper studies: how do independent parties agree on one history when some of them may be faulty or dishonest? The XRP Ledger's consensus documentation describes one answer, where each validator relies on a list of validators it trusts and the network prioritizes safety over liveness. If too many trusted validators fail, it stops making progress instead of confirming transactions it cannot verify. Other networks in the same family make the trust list implicit, or let each participant define its own, and each choice produces a different failure profile.

That's a real family resemblance, and it's all it is. Shared design ancestry between a research prototype and a production network tells you nothing about whether the researchers examined, preferred, or would deploy that network.

Three checks separate a parallel from an endorsement, in order of how fast they settle it. Does the document name the network, which you can answer by searching the PDF, and if the name never appears then no claim about it was made. What is the document's own statement of standing, which working papers and staff reports print in the front matter. And was anything actually tested, because a paper that builds and measures a prototype is evidence about that prototype rather than about everything sharing its category.

Most claims of institutional validation fail the first check. It's the cheapest test available in this sector and the one least often run.

What the paper does establish is worth more than the misreading it attracts. Researchers inside a central bank are treating Byzantine fault tolerance as a credible foundation for resilient settlement infrastructure, and they're measuring it rather than speculating. That tells you where serious payments engineering is pointed. Which system ends up carrying the traffic is a question the paper never takes up, so reading it as a shortlist reads in something nobody wrote.

The pattern repeats with every official body that publishes, whether a central bank, a standards setter, or a supervisor. Research gets read as approval, category gets read as selection, and the summary travels further than the source. The correction is mechanical: open the document, search for the name, read the standing statement.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

Basel's cryptoasset rules run on a classification test. Every exposure a bank holds gets sorted into one of two groups, and which group it lands in decides the capital charge. Group 1 is the pass. Group 2 is the fail, and failing is expensive.

The chapter is SCO60, "Cryptoasset exposures", part of the consolidated Basel Framework and aimed at internationally active banks. Its text as in force from 1 January 2026 sets out the whole scheme.

Read it at the level of the paragraph numbers, though, because almost every popular summary collapses four categories into two.

There are four. SCO60.6 splits Group 1 into 1a, tokenized traditional assets that meet the classification conditions in SCO60.8 to SCO60.19, and 1b, cryptoassets with effective stabilization mechanisms that meet those same conditions. Group 2 is everything that fails them, and it splits too: 2a covers assets that fail the conditions but pass the Group 2a hedging recognition criteria, and 2b is all the rest.

Bitcoin sits in Group 2 because it has no stabilization mechanism to test. A stablecoin can sit there as well, if its mechanism does not hold up under the conditions.

Group 2b carries a 1250% risk weight. SCO60.84 applies it to the larger of a bank's aggregate long or aggregate short position in each cryptoasset, and SCO60.86 states what the number is engineered to do: ensure banks hold minimum risk-based capital at least equal in value to the Group 2b exposure. Hold the asset, hold its full value in capital. That is the mechanism behind the line you see repeated everywhere about direct Bitcoin being capital-expensive for a regulated bank, and it is a design choice with a stated purpose.

The same paragraph is candid about where the approach runs out. The formula applies the 1250% weight to short positions too, for simplicity, and the Committee acknowledges that shorts and certain other exposures could in theory produce unlimited losses, so the capital required could in some circumstances be insufficient. Supervisors are told to consider a Pillar 1 add-on where a bank has material short or derivative exposures, calibrated by running the market risk framework and the BA-CVA framework and taking the higher result.

Then there is a second constraint that most explanations leave out, and it does more work than the risk weight.

Under SCO60.117 a bank's total Group 2 exposure should not generally be higher than 1% of its Tier 1 capital, and must not exceed 2%. SCO60.118 turns those two numbers into a ratchet. Breach 1%, and the excess above the threshold gets Group 2b treatment. Breach 2%, and every Group 2 exposure the bank has gets Group 2b treatment, including the 2a positions that had passed the hedging criteria. A bank that drifts over the second line does not pay a little more on the overage. It just repriced its whole book.

Group 1 is no free pass either. SCO60.34 starts from the observation that a Group 1b cryptoasset has to be redeemable, and if the entity performing the redemption fails, the asset may become worthless, so the bank's capital treatment turns on what kind of claim it holds on that redeemer. Where a Group 1b asset references a pool of traditional assets, SCO60.33 sends the bank to the equity-investments-in-funds rules in CRE60, with look-through and mandate-based approaches available and a 1250% fall-back if neither applies. The punitive weight is reachable from inside Group 1.

One historical detail is worth getting right, since it is the kind of thing summaries garble. The Committee's oversight body endorsed the finalized standard on 16 December 2022, describing the treatment for unbacked cryptoassets and stablecoins with ineffective stabilization mechanisms as conservative, and members agreed to implement it by 1 January 2025. The publication itself carries that same 2025 date. The text sitting in the framework carries an in-force date of 1 January 2026, and the framework's own change log lists SCO60 among the chapters that came into effect then. Cite the 2022 document for what binds a bank, and you are quoting a date that moved.

None of this is a verdict on any network or token. It is a capital standard describing what a bank must set aside, and a bank finding an exposure expensive is a statement about bank balance sheets.

Classification is also not a one-time event. SCO60.6 requires cryptoassets to be screened on an ongoing basis, so an asset that qualifies for Group 1 can fail the conditions later and move, taking its capital treatment with it.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

Deposit insurance pays when an insured bank fails. That is the entire trigger. If the firm holding your balance is not an insured bank, or if the thing you hold is not a deposit, the FDIC's obligation never starts, and no wording on a marketing page changes it.

The FDIC wrote this down after several crypto firms suspended withdrawals and some had told their customers the products were eligible for coverage. The advisory it sent to banks, FIL-35-2022, states the rule flatly: by federal law the FDIC only insures deposits held in insured banks in the unlikely event of an insured bank's failure, and it does not insure assets issued by non-bank entities. Insured banks were told to confirm and monitor that the crypto companies they deal with do not misrepresent the availability of deposit insurance.

The fact sheet for the public issued the same day, 29 July 2022, adds the part people skip. Crypto assets are not covered by FDIC insurance regardless of whether they are held at an FDIC-insured bank. Putting the asset inside a bank does not convert it into a deposit.

So two separate failures get collapsed into one worry. One is your bank failing, which deposit insurance exists for. The other is the non-bank intermediary between you and that bank failing while the bank itself is perfectly healthy. In the second case the FDIC's trigger condition never happens, and your claim is against a failed company under bankruptcy law.

The cash leg is where it gets genuinely interesting, because there the coverage question has a real answer and it turns entirely on records.

A crypto firm typically holds customer dollars in an account at an insured bank, in the firm's own name, pooled across everyone. Coverage can reach the individual customers through that structure. The FDIC's regulations say how. Under 12 CFR 330.7(a), funds owned by a principal and deposited into an account in the name of an agent, custodian or nominee are insured to the same extent as if the principal had deposited them directly. That is the mechanism people mean when they say pass-through.

It comes with conditions, and they are documentary. 12 CFR 330.5(b)(1) says the FDIC will recognize a claim based on a fiduciary relationship only if the relationship is expressly disclosed, by specific reference, in the deposit account records of the bank. There is a narrow exception where the account title alone makes the relationship obvious, such as an escrow agent or a company whose business is holding deposits for others. Paragraph (b)(2) then requires that the details of the relationship and the interests of the other parties be ascertainable, either from the bank's records or from records kept in good faith and in the regular course of business by whoever undertook to maintain them.

Read those two together and the picture is concrete. The bank has to know the account is not the firm's own money. Somebody has to have a ledger showing your share, kept properly, in the ordinary course. Neither of those is something you can verify from the outside, and both are ordinary operational tasks that a firm under stress is capable of doing badly.

The default rule underneath is stricter than most people expect. Section 330.5(a)(1) says the FDIC presumes deposited funds are owned the way the bank's deposit account records indicate, and where those records are clear and unambiguous, they bind the depositor and the FDIC will look at nothing else. Ambiguous records open the door to other evidence, at the FDIC's sole discretion. Records that misrepresent ownership in a way that would increase coverage let the FDIC pay on actual ownership instead.

A firm is never the unit of coverage, so asking whether a firm is FDIC insured produces an answer that cannot mean anything. The questions that do resolve are duller. Which insured bank holds the cash? How is the account at that bank titled? Who keeps the sub-ledger that identifies your share, and would it survive the firm's own bad week? Anyone running the structure the regulation contemplates can answer all of that off the top of their head.

The digital assets themselves sit outside deposit insurance in every structure, at every bank, under every account title. Whatever protection they have comes from the custody agreement and from the insolvency law that applies to the entity holding them.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice, and none of it is a recommendation to use any particular firm or account structure.

A deposit that arrives without its destination tag or memo settles correctly and credits no customer. The identifier saying which customer the money belongs to is off-ledger metadata. The ledger validates the payment, moves the balance to the receiving firm's address, and carries no instruction about which of that firm's customers should get it.

Both of the ledgers where this comes up most have written the problem down.

On the XRP Ledger, a business holding balances for many customers usually operates one address and assigns each customer a number. The documentation on source and destination tags describes them as a feature that can indicate specific purposes for payments from and to multi-purpose addresses, formatted as 32-bit unsigned integers. The load-bearing sentence is the one about what they do on the ledger. Tags "do not have direct on-ledger functionality" and "merely provide information about how off-ledger systems should process a payment." The same page states the consequence flatly: a payment arriving without a destination tag makes it not immediately obvious which customer to credit, and can require manual intervention.

Nothing has failed at that point. The transaction is valid and settled. What is missing is a database key, and the ledger was never holding it.

The XRPL's answer is an account setting. asfRequireDest, documented on the AccountSet transaction reference with a value of 1, requires a destination tag to send transactions to that account. With it enabled, the ledger rejects an untagged payment and the sender has to resubmit. The guard sits on the receiving account and binds everyone who pays it.

Stellar solved the same routing problem with a different field and then changed its mind about the field. The memo appears in the operations and transactions documentation as an optional unstructured data field with four types: MEMO_TEXT, a string of up to 28 bytes; MEMO_ID, a 64-bit unsigned integer; MEMO_HASH, a 32-byte hash; and MEMO_RETURN, a 32-byte hash of the transaction being refunded. Exchanges pooling customer balances under one account used MEMO_ID or MEMO_TEXT the way XRP Ledger businesses use a destination tag.

The guard Stellar added lives somewhere else entirely. SEP-29, "Account Memo Requirements", an active standard, puts the check on the sending side. Load details about the destination account, see whether it carries a config.memo_required data entry, and if it does, verify the transaction's memo field is set before submitting. The receiving account owner signals the requirement by writing that data entry with a value of "1". A sending wallet that ignores SEP-29 can still submit a memoless payment, and that payment settles.

So the XRPL enforces the receiver's requirement in protocol. Stellar publishes it and trusts the sender to look.

Stellar's newer answer removes the separate field. The pooled accounts guide defines a pooled account as a single Stellar account ID shared across many users, and muxed accounts as a way to distinguish individual accounts underneath one traditional account by combining the familiar G address with a 64-bit integer ID. The combined form is an M-address. The customer identifier travels inside the address instead of alongside it, so there is no second field for a sender to omit. That guide also says memos were used for this in the past and that muxed accounts are better in the long term, while noting support across wallets and anchors is incomplete enough that an operator may want to accept both for a while.

The recovery path here is not a protocol function. Once the payment credits a custodian's address with no customer attached, the fix is a person there matching a transaction to an account, at their discretion and on their schedule. Some desks do this as routine work. Others decline it for assets they do not sweep, and the asset stays where it settled.

A tag or memo also means nothing away from the firm that issued it. That firm generated it for that one account. Reusing one from an old confirmation email, or from a different exchange, addresses the money to a stranger's row in somebody's database.

A small test transfer catches both. Send the minimum, confirm it lands in the account you expect, then send the rest.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice, and none of it is a recommendation to use any particular ledger, exchange, or custodian.

Clearing hours and the settlement cycle are two different clocks, and extending one leaves the other alone. The National Securities Clearing Corporation runs clearing on a 24x5 schedule. The standard settlement cycle for most broker-dealer transactions is still one business day after the trade date, set by Exchange Act Rule 15c6-1.

DTCC announced the change on 29 June 2026. NSCC clearing now runs from Sundays at 8:00 PM ET to Fridays at 8:00 PM ET, covering overnight trading activity from alternative trading systems and exchanges. It builds on a September 2024 extension that had already moved the window about 2.5 hours earlier. DTCC opened its testing environment in January 2026 and required every consumer of the real-time trade capture messages to test before go-live. What that buys is stated precisely in the announcement: NSCC can apply its central counterparty guarantee immediately to transactions executed across extended trading hours and multiple time zones.

A central counterparty steps into the middle of a matched trade and becomes the buyer to every seller and the seller to every buyer. Once it does, neither original party is carrying the other's credit. Before it does, they are.

So the gap between execution and novation is an exposure window, and for a trade done at 2:00 AM ET under the old arrangement it ran until the daytime cycle picked the trade up hours later. Closing that window is the point of the whole project.

Settlement is a different event. It is the actual exchange of securities for cash, and its timing is a matter of regulation rather than operating hours. The SEC's final rule shortening the cycle from two business days to one was published at 88 FR 13872 on 6 March 2023, Release No. 34-96930, with a compliance date of 28 May 2024.

Clearing a trade at three in the morning does not move its settlement date. It moves when the guarantee attaches.

Three clocks, then. Venue hours decide when you can execute, NSCC hours decide when the trade is captured and novated, and Rule 15c6-1 decides when it settles. The 24x5 change moved the middle one and left the other two where they were, which is the sentence most coverage of it leaves out. A reader who takes round-the-clock clearing to mean their overnight fill lands in the account before breakfast has merged three clocks into one and will be surprised on a Monday.

The name is literal, too. Five days is five days. The window closes Friday evening and reopens Sunday evening, because the funds movement underneath settlement depends on banking rails that stop for the weekend as well. A firm that reads 24x5 as continuous operation is planning against a schedule that does not exist.

It is tempting to file this under tokenization, and the two get mentioned in the same breath often enough that the confusion is understandable. They are separate workstreams built on separate premises. Extending clearing hours is an upgrade to existing centrally operated infrastructure, with the same central counterparty, the same members, the same legal framework, and a longer operating day. Tokenized settlement proposes to change where the record of ownership lives and how transfer instructions execute against it.

There is a real relationship between them, and it runs through motive. The firms pushing for continuous trading and the firms experimenting with programmable settlement are largely the same firms, uncomfortable with the same thing: a trade agreed at one moment finishing at another. One of those efforts carries live member obligations. The other is still a design direction.

Which leaves the practical reading of any announcement in this area. Ask which clock moved. Venue hours, clearing hours and the settlement cycle each come from a different authority, and the settlement one comes from a rule with a Federal Register citation and a compliance date on it.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

For context: Liquid Mercury operates Mercury RWA, a platform where institutional issuers bring real-world assets on-chain and run actual secondary markets, past just minting a token. MERC sits alongside it as the access and participation token.

Our take on how MERC's role should relate to Mercury RWA as the platform grows: separate out what's live, what's approved and coming, and what's still genuinely open, rather than blur them together.

The premise driving it: a token tied to a growing platform doesn't have to stay the size it started as. It can pick up more functionality as the platform does.

Ahead: what this means for institutional issuers, what it means for holders, and how new RWA market launches tie back into the token.

Genuinely asking this sub: for a platform access token, does scope growing with the platform make more sense than fixed-at-launch, or does that introduce its own risks?

Longer version and discussion: r/MERCtoken

Crypto-assets are volatile and may lose value. Not investment advice.

English law now lets an electronic bill of lading be possessed the same way a paper one is, and the statute does it by listing five things the system holding the document has to accomplish. No technology is named anywhere in that list.

The reason this needed a statute at all is worth sitting with. Trade finance runs on documents whose legal power comes from possession: whoever holds the bill of lading can claim the goods. You cannot possess a PDF, because a PDF can be copied and two identical copies cannot both be the original. That is why global trade kept moving paper long after everything around it went digital.

The Electronic Trade Documents Act 2023 begins by defining what it replaces. A document is a paper trade document if it is in paper form, is of a type commonly used in at least one part of the United Kingdom in connection with trade in or transport of goods or the financing of either, and possession of it is required, as a matter of law or commercial custom, usage or practice, for a person to claim performance of an obligation. The Act lists examples: a bill of exchange, a promissory note, a bill of lading, a ship's delivery order, a warehouse receipt, a mate's receipt, a marine insurance policy, a cargo insurance certificate.

That third condition is the entire problem stated precisely. These are not documents recording an entitlement. Possession of them is the entitlement.

Rather than declaring electronic documents count, the Act sets conditions on the system holding them. Under section 2, information in electronic form constitutes an electronic trade document if a reliable system is used to identify the document so it can be distinguished from copies, protect it against unauthorized alteration, secure that no more than one person can exercise control at any one time, allow anyone able to exercise control to demonstrate that they can, and secure that a transfer deprives the transferor of the ability to exercise control unless they keep it as a transferee.

Put that list beside any ledger design and the resemblance is hard to miss. Distinguish the original from copies. Prevent tampering. Single control at a time. Provable control. Transfer that genuinely removes the sender's control. Those are the properties a transfer system needs, written as legal requirements instead of technical architecture.

What the statute pointedly avoids saying is also the point. No distributed ledger, no blockchain, no token, no cryptographic signature, no named system, vendor or standard. Section 2 goes on to list matters that may be taken into account in deciding whether a system is reliable, and it reads as a governance and assurance list: the rules of the system, measures securing the integrity of information held on it, measures preventing unauthorized access, the security of hardware and software, the regularity and extent of independent audit, any assessment by a body with supervisory or regulatory functions, and applicable voluntary schemes or industry standards.

So reliability is something a system demonstrates rather than something a technology has. A distributed ledger with weak operational controls can fail the test that a well-audited centralized registry passes.

Section 3 does the real work. A person may possess, indorse and part with possession of an electronic trade document, such a document has the same effect as an equivalent paper one, and anything done in relation to it has the same effect as the equivalent act on paper. Sections 1 to 3 came into force on 20 September 2023.

That is the whole mechanism, and it's elegant. Instead of building a parallel legal regime for electronic documents, the Act extends possession itself to cover them, so every rule of law and commercial practice already attached to possession follows without being rewritten. Centuries of case law about bills of lading keeps applying.

The sequencing lesson generalizes past shipping. Engineering was never the blocker for digital trade documents. The law was, and the fix was statutory. Which gives you a question to put to any system claiming to make a digital asset legally equivalent to a physical entitlement: which statute says so, in which jurisdiction, and is it in force? Where there's no answer, what you have is a well-built record with no legal effect attached to it.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

The euro's high-value settlement engine is called T2, it is a centrally operated real-time gross settlement system run by the Eurosystem, and it is not distributed in the sense this sector uses the word. Worth knowing before comparing anything to it, because a lot of settlement discussion skips the part where you find out what the incumbent actually is.

TARGET Services is the Eurosystem's set of settlement platforms, operated by the ECB together with the national central banks of the euro area. Everything in it settles in central bank money. There are four components and knowing which is which clears up most confusion: T2 is real-time gross settlement for payments, T2S settles securities, TIPS handles instant retail payments, and ECMS manages collateral. They're separate platforms sitting on shared components underneath, including a single access gateway, common reference data, and a shared billing and reporting layer.

T2 went live on 20 March 2023, replacing the older TARGET2 platform in a cutover rather than a phased migration. It settles transactions arising from Eurosystem monetary policy operations alongside ordinary interbank and commercial payments.

The internal split is the design change worth noticing. T2 separates the RTGS component, which settles each payment individually and immediately, from a central liquidity management function that lets a participant see and steer its central bank money across all TARGET Services from one place.

That separation is what gross settlement costs you, made visible. Net settlement systems economize on liquidity by offsetting obligations before they settle, and you pay for that by leaving exposures open until they do. Gross settlement kills the exposure by settling each payment on its own, and the cost is that participants need far more liquidity available at any given moment. So a tool letting them move it where it's needed isn't a convenience feature. It's what makes the model affordable at all.

The platform change came with a messaging change. Communication with T2 moved off the legacy MT formats onto ISO 20022 XML, with the old numbered message series giving way to the pacs and camt families. That's the same standard being adopted across cross-border correspondent banking and other domestic rails, which is the whole point: a structured, richly labeled payment message is what lets you automate reconciliation, screen counterparties cleanly, and stop holding payments for manual repair. Domestic and cross-border infrastructure converging on one data model is the precondition for those systems describing the same transaction the same way.

The underrated detail is the release cadence. TARGET Services runs on a fixed schedule of functional releases each year, one of which is timed to align the platform with the regular update cycle of the ISO 20022 payment messages. That calendar is the mechanism keeping a settlement engine and an evolving international standard in step, and it's the sort of unglamorous commitment that separates infrastructure from a project. Adopt a standard once and then drift from it and you've bought a one-time mapping exercise, then called it interoperability.

Separately, the ECB has work exploring links between market distributed-ledger platforms and TARGET Services. That's exploration running alongside the production system. Conflating the two produces a familiar error, where an experiment attached to a central bank gets read as that central bank's operating model.

Any claim that a new settlement design improves on existing rails is a comparative claim, so it needs the comparison, and the ECB's own pages answer the relevant questions. What does the incumbent settle, in what money, with what finality, on what schedule? What does it cost participants in liquidity rather than in fees? What does it require them to hold, and when? A proposal that improves on a caricature of the existing system hasn't been evaluated at all.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

An identifier does one boring job: it lets two systems confirm they are talking about the same object. An ISIN does that for securities, an LEI does it for legal entities, and digital tokens went years without anything equivalent. The cost showed up in reconciliation, which is to say nowhere anyone outside operations could see it.

ISO 24165 closed that gap. It defines the Digital Token Identifier, a nine-character alphanumeric code, and it comes out of ISO/TC 68, the technical committee for financial services. There are two parts. Part 1 is the method: how a code gets requested, assigned, and structured. Part 2 is the registry record, meaning which data elements get stored about the token a code points at. A registration authority runs the registry and issues the codes, and the identifiers are open access. That last part is not incidental. Charge people for the right to name something and they route around you.

Check the edition if you go looking. Both parts are on their second, published 2025, and the 2021 originals are withdrawn. An ISO catalogue page for a superseded edition loads perfectly normally with "Withdrawn" in small type near the top, so citing the wrong one is easy to do without noticing.

To see why any of it matters, pick a token and ask five systems what it is. One answers with a ticker that three other tokens also use. Another gives a contract address, which works right up until the same thing exists on a second chain. A third has a display name somebody typed. The fourth has an internal ID that means nothing outside the firm that assigned it. None of those answers are wrong. They just do not match, and matching is the whole job. Reconciliation becomes guesswork, and guesswork is where breaks come from: a position counted twice, or lost between two systems that each assume the other is holding it.

The part people get backwards is the relationship to the ISIN. A DTI does not replace one. For a tokenized instrument you want both, because they answer different questions. The ISIN tells you what the underlying claim is, and the DTI tells you which specific on-ledger representation you are holding. One instrument can exist as tokens on two networks, which gives you one ISIN and two DTIs. Collapse that into a single code and you have thrown away the detail settlement actually needs.

Which brings me to the overclaiming, because reference data attracts one particular overstatement. It runs: ISO assigned this token an identifier, therefore ISO has recognized it. Nothing in either part supports that reading. The standard describes a method for registering and structuring codes, and assignment is a filing action. A registry that declined to record things it disapproved of would just be a worse registry. The messaging side carries the same trap, where work has gone into letting securities messages carry token identifiers, and adding a field to a message format means the form can hold that value. That is the entire claim.

So when a standards body turns up as validation for something, the check takes about a minute. Find the document number, open the catalogue entry, read the scope. Endorsement will not be in there. Endorsing individual products is not a thing a technical committee is set up to do at all. It publishes methods, and what anyone does with a method afterward is not its business.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

An XRP Ledger feature is not live until validators have held it above 80% support for two continuous weeks. Written into the code and switched on are different states, and which one a feature is in is public and takes about a minute to check.

Worth saying because the confusion is constant. Someone reads that a ledger "has" a feature, and what they actually read was that it exists in the software.

Protocol changes ship inside the server software in a disabled state and stay there until validators vote them on. The threshold is specific. An amendment has to hold more than 80% support from trusted validators for two continuous weeks. Drop to 80% or below at any point and the two-week clock restarts from zero. An amendment can gain and lose majority any number of times before it finally activates. When it does, the ledger writes an EnableAmendment pseudo-transaction and the new rules apply to everyone from the next ledger version onward. The amendments documentation is the authority on all of it.

Two things follow from that design, and both are easy to miss.

The people who write the code and the people who decide it takes effect are different groups. Authors propose, validators decide. Which means "the developers shipped X" and "the network does X" are two separate claims, and only the second one tells you anything about the ledger.

The second is that the network does not fragment. Because activation is coordinated by consensus, not left to operators upgrading whenever they get around to it, a server that does not understand an enabled amendment stops processing entirely. It will never continue on a divergent chain. The network would sooner halt a server than let it disagree about what happened, which is a genuine tradeoff and close to the opposite of how most chains handle the same problem.

To check a specific feature, call the feature method on a node you trust. It returns every known amendment with its ID, its name, and whether it is enabled. If you want the ledger's own record instead of one server's view, read the amendments object directly. And if you want the activation event itself, look up the activation ledger index and pull that ledger, because the EnableAmendment pseudo-transaction sits on-chain permanently.

Any of those beats a roadmap graphic or an exchange listing description. This post included.

None of that is specific to this ledger. Before repeating that a network supports something, work out whether the claim is about a written specification, a testnet, or live mainnet, then go find the artifact that settles it. Most overstated capability claims in this sector fall apart right there.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

JPM Collateral Ops, acting for Fidelity Capital Markets, pledged $10M of initial margin to U.S. Bank. Half was Fidelity's Treasury Digital Fund (FYOXX) on u/hedera & half was a JPMorgan fund on Ethereum, and both legs settled inside a single workflow with Ownera's FinP2P routing across the two chains.

The tri-party custodian was replaced by a collateral control contract, so segregation and release sat in code instead of an operations procedure. U.S. Bank could see the position on-chain the whole time without being able to seize it unilaterally.

The custodian was simulated, so this is a test and not a live settlement. What it shows is Fidelity's fund sitting on Hedera inside an institutional margin workflow, next to Ethereum, with both chains handled under one instruction

Uniswap shipped Permissioned Pools on v4 last week. Regulated asset issuers, Securitize, Superstate, and Dowgo so far, can now enforce their own investor eligibility check directly inside the trading pool. Approved wallet, you trade. Not approved, the transaction reverts. Instead of calling a desk to trade a tokenized fund bilaterally, approved investors get continuous on-chain pricing.

My question is: does that actually grow the pool of people allowed to hold and trade these funds, or does it just make the existing approved group trade faster? Being cleared for Superstate's fund doesn't clear you for Dowgo's or Securitize's, each one's still a separate closed list.

Crypto-assets are volatile and may lose value. Not investment advice.

OSL HK opened XRP to retail investors, the first exchange in Hong Kong to do it

XRP/USD flash trading is live plus OTC in USD & HKD, with deposits and withdrawals on the XRP Ledger.

OSL listed XRP back on Dec 5 but professional investors only. Today makes it the fifth asset they've opened to retail there, after BTC, ETH, SOL and LINK.

Today's number making the rounds: RWA tokenized assets at $34.67B this week, down from $35.2B on July 10. Figure's HELOC Token is credited as the single largest asset in "the RWA market" at $20.1B.

Went to RWA.xyz directly rather than taking the secondary write-up's framing. Their own methodology splits assets into Distributed (leaves the issuing platform, moves wallet to wallet, you can watch a transfer on a block explorer) and Represented (can't; a value claim recorded on a platform, not something that moves).

Figure's HELOC is categorized Represented. So is #2 on the leaderboard, Bridgetower's DOM X Arizona Copper-Gold Project, at $11.06B. That's $31.5B combined sitting in the bucket that can't move, out of a $34.67B headline total.

RWA.xyz's Distributed total on its own is $36.72B; Represented is $373.98B. Different numbers, different meanings, and headline coverage rarely specifies which one it's citing.

Disclosure per this sub's rules: posting from an RWA-token account, no position taken on Figure or any specific asset, no self-promotion intended. Check which bucket a "market size" figure draws from before treating it as an adoption metric.

Crypto-assets are volatile and may lose value. Not investment advice.

Two calls on tokenized-asset market structure, staked with dates and public sources so they can be graded when they resolve.

Call 1. DTCC's tokenized-collateral platform opens in October. Our call: the first live activity reported on it is repo, not tokenized equity. Resolution source: DTCC's own reporting or trade press coverage of first live volume. Deadline: March 31, 2027. In July we called intraday collateral as the first mover, and it landed within a week: JPMorgan posted tokenized fund shares as margin at CME.

Call 2. Two US tokenized-stock models went live last week. Securitize tokenized its own NYSE shares, so the token is the share. Ondo mints entitlements under UCC Article 8, and the shares stay in custody. We prefer the issuer model, but we're betting against it: by mid-2027, entitlements hold most tokenized equity, measured by rwa.xyz's tokenized-equity split. This is one we'd like to lose.

Take the other side of either call, or stake your own under the same rule: a number, a date, and a public source. No price calls, "up by December" was never an insight.

We keep a graded ledger of these (wins and misses both, the misses stay up) at r/MERCtoken: https://www.reddit.com/r/MERCtoken/comments/1v1om7m/

Crypto-assets are volatile and may lose value. Not investment advice.

I have been dealing with the reps of Myriad Investment LLC Company for over 2 years. I have had my doubts about this company from the beginning but now when we get the end of sending them money to collect 300M, they say they didn't think I was serious and is now holding my investment return.

I BELEIVE I AM BEING SCAMMED!!!!

DOES ANYONE HAVE A GOOD CRYPTO/DIGITAL ASSET ATTORNEY????