> ## Documentation Index > Fetch the complete documentation index at: https://docs.digitalasset.com/llms.txt > Use this file to discover all available pages before exploring further. # 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: > **[Direct Ledger API access](#1-direct-ledger-api-access)** > > Grant the provider read access to your existing Canton participant node. > **[Party replication](#2-party-replication)** > > Replicate your party to a participant node operated by the third-party provider, in observation or confirmation mode. These approaches differ in infrastructure requirements, operational responsibilities, and security considerations. > [!WARNING] > > Both approaches provide **party-level** data access. They do not automatically restrict the provider to specific instruments, transaction types, or application workflows. The scope of information available depends on the party's visibility and the permissions granted. ## 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: **1. Identity and access management** Create a dedicated user account for the third-party provider in the identity management system connected to the Canton participant node. See [Canton authorization](https://docs.canton.network/appdev/deep-dives/authorization). **2. Ledger API permissions** Grant the user read-only access to the relevant Canton party, such as the asset registrar party. See [Ledger API User Management — CreateUser](https://docs.canton.network/reference/grpc-ledger-api-reference/com-daml-ledger-api-v2-admin/usermanagementservice/createuser). **3. Network access** Configure the required network and firewall rules, such as allowlisting the provider's IP addresses in the Web Application Firewall, or exposing access through a secure API proxy. **4. API connectivity** Provide the provider with the API endpoint and the authentication mechanism required to connect. 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: | API | Purpose | | - | - | | `/v2/version` | Retrieve participant version information | | `/v2/state/ledger-end` | Determine the current ledger offset | | `/v2/state/latest-pruned-offsets` | Determine the available historical data range | | `/v2/updates` | Retrieve transaction updates | | `/v2/updates/get-updates-page` | Retrieve paginated transaction updates | | `/v2/state/active-contracts` | Retrieve the Active Contract Set (ACS) | | `/v2/packages` | Retrieve installed package information | > [!NOTE] > > The exact endpoint availability and request formats depend on the deployed Canton version. Providers should consult the participant's OpenAPI specification. 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. > [!TIP] > > Providers may also require instrument metadata, such as the instrument identifier, issuing authority, identifier scheme, and relevant synchronizer information, to correctly identify and classify assets. ### 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. > [!WARNING] > > Canton participants may prune historical transaction data. The provider and participant operator should agree on the required history retention period and any initial backfill requirements. Where complete asset history is required, the operator must ensure that the necessary history is retained or made available through an appropriate backfill mechanism. ### 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](https://docs.canton.network/sdks-tools/api-reference/ledger-api) * [Ledger API User Management — CreateUser](https://docs.canton.network/reference/grpc-ledger-api-reference/com-daml-ledger-api-v2-admin/usermanagementservice/createuser) * [Canton Token Standard — Transaction History Parsing](https://docs.digitalasset.com/registry/guides/tx-history-parsing.md) * [Canton authorization](https://docs.canton.network/appdev/deep-dives/authorization) * [CIP-0056](https://github.com/canton-foundation/cips/blob/main/cip-0056/cip-0056.md) * [CIP-0112](https://github.com/canton-foundation/cips/blob/main/cip-0112/cip-0112.md) ## 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. **Observation mode** ### 2.1 Party replication in observation mode In observation mode, the third-party participant receives transaction data relevant to the replicated party but does not participate in transaction confirmation. This is suitable for third-party services that require read-only access to transaction data, such as: * KYT and AML transaction monitoring * Accounting and reconciliation * Transaction analytics and reporting The provider can access the replicated party's transaction data through the Ledger API of its own participant node. **Confirmation mode** ### 2.2 Party replication in confirmation mode In confirmation mode, the third-party participant receives transaction data and additionally participates in the Canton transaction confirmation protocol. This provides the same data-access capabilities as observation mode, with the additional benefit of supporting a more resilient party-hosting configuration. For example, a registrar party hosted on multiple confirming participants can reduce its dependency on a single participant node. With an appropriate confirmation threshold and hosting configuration, transactions may continue to be confirmed even if one participant becomes unavailable. This can help eliminate a single point of failure (SPOF) at the participant-hosting level and improve the operational resilience of the registrar party. > [!NOTE] > > The resilience benefit depends on the configured confirmation threshold and the availability of the remaining confirming participants. Confirmation hosting alone does not guarantee failover or eliminate all operational dependencies. ### 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: > **Infrastructure isolation** > > The third-party provider does not require network access or API credentials to the issuer's participant node. Each organization manages its own infrastructure, security controls, and API access. > **Protocol-enforced data consistency** > > With party replication, the third-party participant receives transactions through the Canton protocol and independently processes the data relevant to the replicated party. > > This reduces the need to trust the registrar's participant operator to selectively provide complete and accurate transaction information through a separate data-sharing interface. > > The Canton protocol provides the underlying transaction authorization, integrity, and consistency guarantees, rather than relying on a custom integration controlled by the data provider. 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 **1. Third-party participant** The service provider operates a Canton participant node connected to the relevant synchronizer. **2. Party replication** The party is replicated from its existing participant to the provider's participant using the supported party replication procedure. **3. Hosting permissions** The replicated party is configured with observation or confirmation permissions, depending on the required capabilities. **4. Application packages** The provider maintains the required Daml Archive (DAR) packages for applications used by the replicated party. **5. Ledger API access** The provider configures a user with appropriate read permissions on its own participant node. Once configured, the third-party provider can access the replicated party's transaction data through the Ledger API of its own participant node. > [!WARNING] > > For parties with existing transaction history, the supported offline replication procedure must be followed, including the transfer of the Active Contract Set (ACS). Historical transaction availability should be assessed separately. ### 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](https://docs.canton.network/global-synchronizer/production-operations/party-management#party-replication) * [Canton Ledger API](https://docs.canton.network/sdks-tools/api-reference/ledger-api) * [DA Covalidation Service](https://docs.digitalasset.com/covalidation/overview.md) ## 3. Comparison | | Direct Ledger API access | Party replication — observation | Party replication — confirmation | | - | - | - | - | | **Data access** | Asset issuer participant's Ledger API | Third-party participant's Ledger API | Third-party participant's Ledger API | | **Additional participant required** | No | Yes | Yes | | **Access to issuer infrastructure** | Required | Not required | Not required | | **Transaction visibility** | Read-only | Read-only | Read-only via API, plus protocol confirmation | | **Transaction confirmation** | No additional confirmer | No | Yes | | **Registrar resilience** | No additional redundancy | No confirmation redundancy | Can improve resilience | | **Data integrity** | Relies on source participant's API | Protocol-enforced | Protocol-enforced | | **Infrastructure operated by third party** | API client | Canton participant | Canton participant | | **DAR maintenance** | Existing participant operator | Third-party operator | Third-party operator | | **Primary consideration** | External API security | Independent data access | Independent data access and resilience | ## 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. > [!NOTE] > > Party replication offers additional security and trust benefits by eliminating the need to expose the issuer's participant API and using Canton protocol guarantees for transaction data integrity and consistency. > [!NOTE] > > **Important:** These approaches provide party-level data access. They do not automatically restrict the provider to specific instruments, transaction types, or application workflows. The scope of information available depends on the party's visibility and the permissions granted.