Banking networks need to communicate. Cacti shows why connections also require clear responsibility

A tokenised asset can work flawlessly in one network and still be difficult to use at another institution. The problem need not be speed. Each party may determine the rightful owner, the point when a transfer is complete or the procedure during an outage differently. Connecting two technologies therefore raises questions that the individual systems did not have to address independently.

September's news around LF Decentralized Trust highlights two parallel changes: more financial institutions are joining open development, and Cacti infrastructure is expanding its tools for cooperation between independent networks. For companies, what matters is the ability to complete a specific transaction safely and document its outcome. The number of connected databases is only a supporting indicator.

Summary for readers

• On 24 September, LF Decentralized Trust announced fifteen new members, including Swift and Wells Fargo; membership alone does not establish their production deployment of Cacti.
• Cacti 3.0 provides tools for asset transfers, event monitoring and auditing across different networks. The version was released in August; the September announcements introduce it to the wider market.
• As of the verification date, the associated SATP protocol is still undergoing the IETF standardisation process. Technical compatibility does not automatically settle contracts, asset eligibility or operators' responsibilities.

Two announcements that should not be conflated

LF Decentralized Trust's announcement of 24 September names fifteen new members and separately summarises developments across several projects. Swift and Wells Fargo are among the members. The document also mentions Cacti 3.0, new initiatives and professional events.

This combination does not establish that all the named banks use all the products presented. Membership represents participation in an open development ecosystem. Evidence of specific operations would need to identify the solution used, the institution's role, transaction scope and operating conditions.

Timing is equally important. The repository records the release of Cacti 3.0.0 on 19 August, while the detailed project blog appeared on 10 September. The September membership announcement therefore does not mean that the software came into existence only on the day it was published.

What changes when assets move between networks

According to the project overview, Cacti 3.0 strengthens transfers through SATP-Hermes, adds support for verifiable views across multiple networks and expands event monitoring. Operational tools include audit interfaces and record retention. Separating the protocol itself from adapters for individual networks is intended to make them easier to connect.

Consider an illustrative situation: a business holds a digitally recorded claim in its bank's system and needs to use it at another institution. Sending a message that the claim exists is not enough. The receiving party must know whether the transfer is permitted, whether the original record remains freely usable at the same time, and how to identify the final outcome.

Coordinating state changes is a different problem from simply sharing information. Displaying a balance may help with checks. It does not, by itself, transfer rights. This distinction explains why the infrastructure has several components and why a universal statement that “the networks are connected” does not provide enough information for a commercial decision.

The protocol envisages operators making specific guarantees

The proposed SATP architecture uses gateways between networks. It assumes identified owners of these gateways, message signing and operators' responsibility for the relevant actions. Before a transfer, ownership of the asset, authorisation to transfer it and eligibility of its type on the destination side are checked.

For a non-programmer, this is essential information. Connecting networks does not mean technology removes the need for trust. Trust is assigned specific points and control conditions. A contract must determine who is responsible for the gateway, exactly what it confirms, and how a dispute between a technical record and a legal claim is resolved.

In corporate practice, it therefore makes sense to start with a simple overview of roles. Who submits the request, who approves it, who confirms completion and who communicates in the event of failure? If suppliers give different answers, the project is not ready simply because they managed to send a test message between their systems.

An outage test reveals more than a smooth demonstration

The SATP-Hermes documentation and Cacti releases describe tools intended to help track transfers. The IETF architecture draft also addresses recovery following a gateway crash. The scope of a specific implementation and its verification nevertheless remain separate questions.

For the customer, a useful test is the point when the first system has initiated a transfer but the second has not yet confirmed completion. It must be possible to establish whether the asset is waiting, has been transferred or the process should be reversed. An instruction repeated without checks must not create a second transaction. Operators need an unambiguous procedure and a traceable history.

These requirements are an editorial proposal for an acceptance test, rather than a claim that the published version automatically covers every combination of networks. Open-source code allows inspection and modification. It does not replace an integrator's responsibility for the specific configuration, security and operational support.

A standard develops gradually

The IETF SATP working group publishes drafts of the protocol, architecture and use cases. As of 25 September, the relevant documents remain drafts in an ongoing process. The designation Internet-Draft should therefore not become a completed, approved standard in an article or service offer.

The core protocol draft seeks a common way to coordinate transfers between gateways. For investment in integration, this is a useful direction, but also a reason to work with versions. The contract and technical documentation should identify the specific supported version of the protocol and the rules for updating it.

A company can thereby avoid a situation in which two suppliers both promise support for the same abbreviation but each means a different version or subset of functions. Practical compatibility arises only from verifying a shared scenario, rather than comparing logos in a presentation.

What Czech and Slovak companies can take from this

When choosing a solution, it is worth requesting a description of one actual flow: where the asset comes from, who receives it, which right remains after the transfer and how the outcome is documented. Next come the cost of connection, its maintenance costs and the procedure for changing providers. General support for numerous networks is useful only if it matches the company's needs.

A well-designed pilot can start with a single asset type and two known counterparties. Alongside a successful transaction, it should include rejection, interruption and recovery. Measures can include the number of manual interventions, the time for which an asset is locked, and the ability to reconstruct what happened. These results are more understandable to company management than the number of technical connectors.

Cacti provides concrete building blocks for such verification. Its broader significance lies in shifting attention from an isolated record to a controlled transfer between institutions. Whether that transfer suits an actual transaction will be determined jointly by technology, contractual arrangements and the people responsible for operations.

Sources

LF Decentralized Trust: fifteen new members, 24. 9. 2026

LF Decentralized Trust: Hyperledger Cacti v3, 10. 9. 2026

GitHub: Cacti v3.0.0 release, 19. 8. 2026

Cacti: SATP-Hermes documentation

IETF: SATP working group and document status

IETF: Secure Asset Transfer Protocol draft

IETF: Secure Asset Transfer Interoperability Architecture draft

IETF: SATP use cases draft, version 10

Cacti: contribution and open development rules

Ledger Insights: Cacti, Swift and Wells Fargo — editorial lead

Methodological note

The sources are closed as of 25. 9. 2026. The text distinguishes the software release date, the project's September communications and the current status of the IETF drafts. Institutional membership is not presented as evidence of production deployment. The illustrative transfer and acceptance tests are the author's interpretation. No security audit of Cacti or verification of a specific banking implementation was performed.

Disclaimer

The article is for information and education. It is not investment, legal or technological advice for a particular project. Using the tools mentioned requires a separate assessment of rights, risks and operating conditions.