Third-Party Data Access

​

Overview

For compliance reasons, asset issuers might require Know Your Transaction (KYT), Anti-Money Laundering (AML) monitoring, accounting, and other data-driven services to be set up before issuing assets on Canton. On public blockchains, third-party service providers can independently index transaction activity. In Canton, transaction data is private by design and only visible to its informees. Third-party providers therefore require explicit access to the relevant transaction data to deliver their services. There are two approaches to granting a third party access to your private Canton transaction data: These approaches differ in infrastructure requirements, operational responsibilities, and security considerations.

​

1. Direct Ledger API access

This approach grants the third-party provider read access to a given party via the Ledger API of one of your existing Canton participant nodes. This allows the provider to retrieve transaction data directly from your infrastructure without operating its own Canton participant node. Access can be provided directly or through an API proxy, using the authentication and authorization mechanisms configured by the participant operator.

​

1.1 Access configuration

The participant operator must configure access for the third-party provider. This typically involves the following steps: The provider can then retrieve transaction data visible to the authorized party, subject to the participant’s available history and pruning configuration.

​

1.2 Required API capabilities

Third-party providers typically use the official Canton Ledger API v2 to retrieve transaction history, current contract state, and relevant application metadata. For transaction monitoring, accounting, and reconciliation services, the following API capabilities are relevant: For asset transaction monitoring, the TRANSACTION_SHAPE_LEDGER_EFFECTS format allows providers to retrieve visible transaction events, including exercised choices, required to interpret asset movements.

​

1.3 Historical data and reconciliation

Depending on the service, third-party providers may require access to both historical transactions and the current Active Contract Set. For example:

• KYT/AML monitoring: Transaction updates are required to identify and classify asset movements.
• Accounting and reconciliation: Historical transaction events and contract state can be used to reconstruct and validate asset balances.
• Transaction analytics: Historical activity can be used to generate reports and identify transaction patterns.

The participant operator must ensure that the required historical data is available.

​

1.4 Considerations

Advantages

• No additional Canton participant node is required.
• Access can be managed through existing IAM and participant infrastructure.

Operational requirements

• The participant operator must provide secure API access to the third-party provider, either directly or through a proxy.
• The participant operator is responsible for managing permissions, network connectivity, and access revocation.
• The participant operator must ensure sufficient API availability and capacity for the third-party integration.
• The participant operator must maintain the historical transaction data required by the provider, taking pruning and backfill requirements into account.
• The third party relies on the participant operator to provide access to the required transaction data.

​

References

• Canton Ledger API
• Ledger API User Management — CreateUser
• Canton Token Standard — Transaction History Parsing
• Canton authorization
• CIP-0056
• CIP-0112

​

2. Party replication

The second approach uses Canton’s protocol-native party replication functionality to replicate an existing party to a participant node operated by the third-party service provider. Party replication enables a Canton party to be hosted on multiple participant nodes. This allows the third-party provider to receive and access the party’s transaction data independently, without requiring direct access to the asset issuer’s participant infrastructure. Party replication provides two configuration options, depending on whether the third-party participant should only observe transactions or also participate in transaction confirmation.

​

2.3 Security and trust model

Party replication provides a protocol-native alternative to granting external access to an existing participant’s infrastructure. Rather than relying on the participant operator to expose transaction data through an API, the third-party provider operates its own participant and receives transaction data through the Canton protocol. This offers two important advantages: Party replication therefore provides a stronger trust model for third-party monitoring and analytics services, while preserving Canton’s permissioned data visibility.

​

2.4 Configuration

Once configured, the third-party provider can access the replicated party’s transaction data through the Ledger API of its own participant node.

​

2.5 Considerations

Advantages

• No ongoing access to the issuer’s participant infrastructure is required.
• Stronger infrastructure isolation between issuer and third-party provider.
• Protocol-enforced integrity and consistency for all transactions after onboarding.
• Independent Ledger API access and pruning control through the provider’s own participant.
• Optional confirmation hosting can improve registrar-party resilience and reduce participant-level single points of failure.

Operational requirements

• The third-party provider must operate and maintain a Canton participant node connected to the relevant synchronizer
• The provider must vet the required DAR packages used by the replicated and keep them updated and aligned going forward.
• Party replication requires coordination and authorization between the existing participant operator and the receiving participant operator, including topology authorization by the party.
• For offline party replication, the receiving participant must be disconnected from all synchronizers from before the ACS import until the import completes. This affects every party hosted on that participant, not only the party being replicated. Providers serving multiple issuers should plan for this downtime on each new onboarding.
• The receiving participant must be backed up before the ACS import. The documented steps must be followed in the exact order.
• Only the Active Contract Set is transferred. Transaction history from before the replication point is not available on the provider’s participant. Where historical data is required, for example for KYT/AML lookback, a separate backfill must be agreed with the issuer, such as temporary Ledger API access to the source participant.

​

References

• Canton Party Replication
• Canton Ledger API
• DA Covalidation Service

​

3. Comparison

​

4. Choosing an approach

Direct Ledger API access is suitable when the participant operator is willing and able to provide secure external API access and the third-party provider does not operate Canton infrastructure. Party replication in observation mode is suitable for providers requiring independent, read-only access to transaction data without participating in transaction confirmation. Party replication in confirmation mode is suitable when independent data access should be combined with improved resilience for the replicated party, such as a registrar party.