Document type: reference guide

Service terms: unavailable

This page explains how to review documents for a service that connects an interface, an account and a network transaction. It is reference information, not an agreement with DTCC Trading. Verified service terms, a responsible operating entity and an available transaction service are not established here. The sections distinguish the roles and records a reader would need to understand before relying on a connected service.

A connected interface can bring several participants into one screen. The website, wallet, account provider and intended recipient can each perform a different task. Read their roles separately.

A name used throughout a document needs a precise definition. Determine whether it identifies one organization, a group of organizations or a particular product. The definition should not leave the responsible party to inference.

Keep the agreement itself separate from the action used to acknowledge it. A document should identify the version presented, the participant accepting it and the service activity it covers. If several documents are referenced, record their titles and dates so that their relationship remains clear when one is later revised. A visible checkbox alone does not explain those details.

Reading an acceptance statement

An acceptance section should explain when a proposed agreement would begin to apply. Compare the stated trigger with the actual activity described: opening an information page, connecting an account and authorizing a transaction are different events. The text should make clear which participant acts and which document the action refers to.

Read the scope of a proposed agreement before interpreting a control as acceptance.

1. Working terms

The following terms help organize a service-document review:

1.1. Compliance references: A reference to a regulatory framework should identify the activity and organization it concerns. Distinguish a requirement described for an account provider from a requirement described for a merchant or interface operator. Record the jurisdiction, source and date supporting each statement. A familiar acronym does not establish that a particular entity is licensed, that a specific check is performed or that responsibility has moved from one participant to another.

1.2. Confidential information: Information described as nonpublic can include business records, technical material and personal details. Read the definition alongside its exclusions and the purpose for which a recipient may use the information. A confidentiality label and a privacy classification answer different questions.

1.3. Fiat currency: A national currency reference needs a currency code and context, including whether it denotes an amount or a payment method.

1.4. Asset amount: A quantity together with its asset identifier.

1.5. Digital asset: An asset represented in digital form. A useful description names the asset, the network and any issuer or contract identifier needed to distinguish it from similarly named representations.

1.6. Privacy references: Documents describing how information is collected and used should identify their responsible parties and scope. Read any regional supplement with the main notice. A privacy reference in service terms should lead to a document covering the same interaction and version context.

1.7. Personal information: A record can identify someone directly or through its relationship with other records. Account details, communication history and technical identifiers need context. A public address can form part of a broader record without identifying its controller on its own.

1.8. Interface: The visible controls through which a person reads information or starts an interaction. Distinguish this presentation layer from the system that creates a request, the wallet that approves it and the network that records an outcome. An embedded panel does not establish who controls an asset.

1.9. Website reference: DTCC Trading.

1.10. Service scope: The specific activities described by an applicable document. A useful scope identifies the participant, channel and operation instead of grouping every connected feature under one broad label.

1.11. Site: The domain and pages covered by a document, distinguished from external pages reached through its links.

1.12. Transaction: A proposed or recorded operation on a specified network. The request, authorization, submission and confirmed outcome are separate states.

1.13. Wallet: A tool or arrangement for managing access to network accounts. An address alone does not establish the signing arrangement.

1.14. Widget: A panel embedded in a page. Identify its function, source and responsible service before assuming the surrounding website performs the panel’s operations.

1.15. External participant: A person or organization with a separately described role in the interaction.

1.16. Read defined terms in their surrounding clauses; the same everyday word can have a narrower document-specific meaning.

2. Parties and service scope

2.1. Start an entity review with the exact legal name in the applicable document. Compare that name with the service description and authoritative record for the stated jurisdiction.

2.2. Keep these identifying details together:

Legal name and record

Place of establishment

Verified service and contact relationship

2.3. Draw a simple sequence of the participants involved in an interaction. Identify who displays the request, who receives the instruction and who is expected to record its outcome. Assign each statement to its source.

2.4. Connecting an account can expose information or enable particular requests. The connection description should explain what is made available, which permissions are requested and where a later authorization takes place.

2.5. Trace asset control separately from interface access. Identify the sending account, intended destination and party able to authorize movement at each stage. A direct-looking screen flow does not prove that no intermediary holds assets or that a custody arrangement exists.

2.6. Network confirmation: Read the states used by the relevant network and service. A prepared request, signed instruction, broadcast transaction and confirmed result are not interchangeable. A useful record identifies the network, transaction identifier, observation time and reported outcome. If the outcome is uncertain, locate the existing record before interpreting a new attempt as a safe continuation. Confirmation claims should refer to evidence for the particular operation.

2.7. Amounts, destinations and timing

An instruction can contain an asset quantity, destination and timing condition. Review them together with the network and any required reference field. Determine which values come from the recipient and which are calculated by a service. A countdown or amount display needs an explanation of what happens when its stated condition is no longer met.

2.8. Separate a network charge from a service fee, an exchange withdrawal charge and a quoted conversion amount. Record the unit and participant associated with each cost. A single total can obscure which charges are estimates, which are fixed for a stated interval and which are only known after processing.

3. Review roles

3.1. A compliance description should connect a stated check to the party performing it. Identity review, monitoring, screening and reporting are distinct activities. For each, identify the applicable service, jurisdiction and documentary basis. Broad references to another participant’s obligations do not explain how a particular workflow operates.

3.2. Where responsibilities are divided, look for the boundary between them. A document should make clear what one participant receives from another and which decisions remain separate.

4. Access scope

4.1. An eligibility description should explain:

4.1.1. The person or organization category to which the stated access conditions apply;

4.1.2. Any capacity or authority needed for the described activity;

4.1.3. The locations, account types or other conditions covered by the applicable service document and its current version.

4.2. Account connection details

A connection flow should distinguish reading an address from asking for a signature, opening a session or proposing a transfer. Identify the permissions displayed, the system requesting them and any stated duration. The document should explain how a person can recognize the active connection and what ending it changes. Review whether a connection is associated with a particular browser, device or account. If an exchange or another hosted account is involved, its own access and authorization procedures also need to be understood in context.

4.3. An eligibility statement and a technical access check serve different purposes. Record what a document says is required, what the interface actually asks and which participant assesses the result. Do not infer approval from merely reaching the next screen.

4.4 Account and device security: Security information should describe the scope of a connection and the controls used by its responsible provider. Separate a website session from the wallet or exchange access used to authorize activity. Review the named support route in the provider’s own current documentation before sending a report. A useful incident description records the time, visible action and public transaction reference without including recovery phrases, private keys or authentication codes. Those secrets are not needed to explain a visible interface problem.

4.5 Conversion and external protocols: If a proposed operation includes a conversion, identify it as a distinct stage. Establish the input and output assets, networks, route and participant responsible for constructing the request. Review any approval, spending limit or contract interaction presented by the wallet. The displayed result should explain whether an amount is an estimate or an observed outcome and how fees or route changes affect it. A protocol name alone does not establish that a contract has been reviewed, that a bridge is involved or that the destination accepts the resulting representation. Each link in the sequence needs its own source and current context.

5. Verification records

5.1. A verification description should identify the party requesting information, the purpose of the check and the service activity to which the result applies.

5.2. Distinguish a completed check from a statement that checks may be required. The document should explain which participant assesses the result and what any status label means.

5.3. Information supplied for a review:
A request for additional records should explain its recipient, purpose and scope. Read that explanation alongside the applicable privacy notice. Transaction details, identification information and technical logs have different roles; a broad request should not be treated as a description of every field needed.

6. Reading risk notes

6.1. Price movement, transaction status and access to an asset are separate sources of uncertainty.

6.2. Match each risk statement to the activity described. Reading asset information, connecting an account and authorizing a transfer do not expose a person to identical conditions.

6.3. A network delay is different from a rejected request or a confirmed failure. A useful explanation identifies the observed state and the source that reports it instead of describing every delay as a lost transfer.

6.4. Records for a transaction should distinguish the asset, amount, time, fees and network outcome. Keep those factual details separate from any tax treatment, which depends on the relevant circumstances and rules.

6.5 Information and professional judgments: An educational explanation describes concepts and evidence; it does not establish whether an activity suits a particular person. Separate statements about how an interface works from conclusions about an asset’s value, legal treatment or tax consequences. When evaluating a claim, identify its author, scope and supporting record, and recognize which questions require a qualified assessment of individual circumstances.

7. Data use

7.1. Connect the privacy notice to the actual interaction. It should identify the organization responsible for the information and the activity covered by its explanation.

7.2. For each data category, distinguish what is entered directly, generated by an interface or received from another participant.

7.3. A security description should connect its controls to the information and process involved. Access restrictions, communication protection and internal handling rules address different parts of the data lifecycle. General assurances are less informative than a clear explanation of their scope.

7.4. Privacy details belong in a notice that matches the service and responsible party. The related privacy information provides a framework for reading categories, purposes and recipients. Follow the actual notice’s cross-references and version details before treating a statement from another document as part of the same explanation.

7.5. Retention statements should distinguish the reason for keeping a record from the period or criteria used to determine its duration. Read any exceptions with the category and purpose they describe.

8. Incident information

8.1. An incident statement should explain what event is being described, which records or systems are affected and what has been established so far. Separate confirmed observations from matters still under investigation.

8.2. Reading an incident update:
Organize the information around three questions:

(a) What happened, when was it observed and which service or record was affected?
(b) Which participant is responsible for communicating verified information?
(c) What action or further update does the documented response describe?

8.3. Recovery information should identify what is being restored and how its status is checked. Restoring access to an interface does not by itself establish that every underlying record is complete.

9. Reading restrictions and scope conditions

9.1. A restriction statement needs a current source, a responsible entity and a defined service activity. Read the geographic and participant scope together. A list copied from another service or an older document does not establish present access conditions. The relevant official sources and the service’s own current terms are needed to assess the stated rule.

9.2. Location and cross-border references:
Distinguish a person’s residence, current location, organization and transaction destination when a document refers to geography. These are different facts and can be used for different purposes. The explanation should identify which fact matters to the stated condition, who assesses it and which document supports the condition.

9.3. Activity categories

An activity restriction is clearer when its categories explain the subject and boundary of the rule:

9.3.1. Goods whose distribution is restricted in the relevant jurisdiction;
9.3.2. Products that require specific authorization or handling controls;
9.3.3. Material involving exploitation or unlawful harm to a person;
9.3.4. Activity connected with fraud or concealment of unlawful proceeds;
9.3.5. Goods or material used without the relevant ownership or usage rights;
9.3.6. Schemes whose stated structure or representations are deceptive;
9.3.7. Content categories governed by a separately described service restriction;
9.3.8. Services subject to location-specific or professional requirements.

9.4. Category boundaries:
A broad label should be read with its examples, exclusions and applicable service context. Similar activities can require different review.

9.5. Technical conduct
should be described in specific terms:

(a) Access attempted outside the permission granted for a particular account or interface;
(b) Actions that interfere with the availability or integrity of a system and its records;
(c) Attempts to bypass a documented access control or another participant’s authorization;
(d) Requests that misrepresent an identity, destination or intended operation;
(e) Automated interactions whose scope differs from the interface or API access described by its provider;
(f) Activity performed through another participant without a clear and relevant authorization.

9.6. Where a document describes restricted access, read the decision process alongside the stated reason. Identify the participant that makes the decision, the affected function and any available review procedure. The description should distinguish a temporary technical block from a longer service restriction or an account-specific outcome.

10. Availability and maintenance

10.1. Service availability should be described for a named interface, system or function and a stated observation period.

10.2. A maintenance explanation can distinguish several kinds of interruption:

(a) A planned change to the application or its underlying software;
(b) A security-related update to a particular component;
(c) Work affecting a server, account interface or network connection;

(d) An incident affecting the operation of a named system;
(e) An interruption at an external service used in the documented flow.

10.3. An availability label should explain which action is affected and whether an earlier request has a known outcome. A restored page does not prove that a delayed transaction completed. Review the existing record and the relevant status source before interpreting a service message as confirmation of a particular operation.

11. Nonpublic records

11.1. Read confidentiality statements by information category and permitted purpose. An account record, technical report and business document can have different recipients and handling requirements even when all are described as nonpublic.

11.2. An exceptional-disclosure section should identify the type of request or process involved. Distinguish the circumstances described in a document from evidence that a disclosure has actually occurred in a particular case.

12. Ending access

12.1. A duration statement should explain when a service relationship begins, what activity it covers and which event would bring it to an end.

12.2. Stopping use of a page, closing a connection and ending an account relationship can have different effects.

12.3. A suspension description should name the function affected, the participant responsible for the decision and any documented route for understanding or reviewing the result.

12.4. Reasons and review:
Read the reason given for a restriction alongside the relevant condition, evidence and stated process.

12.4.1. Identify the clause or condition the explanation refers to;
12.4.2. Separate a reported observation from a final assessment;
12.4.3. Determine which participant can explain the decision and whether the document describes a review route.

12.5. Effects of ending access:
12.5.1. Establish which interface or account functions would stop;
12.5.2. Review what happens to requests already in progress;
12.5.3. Read information retention separately from access termination. A document should identify the categories kept, the purposes for keeping them and the period or criteria governing their retention. Ending a connection does not necessarily remove records held by each participant. Public network records, private account records and support correspondence also differ in who can change them. Any deletion description should explain those boundaries and the status of records shared with another party.

12.5.4. A provision describing the consequences of suspension should be read with any exceptions, review process and applicable legal context. Do not treat a broad statement about claims as an explanation of what happened to a particular account, record or pending transaction.

13. Reading service assurances

A warranty section describes the assurances a document makes or limits about a service. Read each statement against the function it concerns: access, timeliness, data accuracy, compatibility and error handling are distinct topics. Identify any qualification, exception or external dependency. A broad availability phrase does not explain measured uptime or verify the accuracy of a displayed value. When a statement concerns another provider, locate that provider’s relevant document and scope. Keep descriptions of expected behavior separate from evidence that a particular request completed as intended. The meaning and effect of an operative clause require the applicable agreement and legal context.

14. Asset control and custody

Asset control needs its own evidence. Trace who can authorize an operation, where assets are held and which account receives them. A service that displays a transaction request can have a different role from a custodian, exchange or wallet provider. Read the documented control arrangement and compare it with the requested permissions and actual network record. An address may require an additional reference field or a particular asset representation; its visible format alone does not establish compatibility. A custody claim, a direct-transfer claim and a claim about safeguarding funds each need support for the specific service and stage described.

15. Electronic records and notices

An electronic-communication section should identify the records provided, the channel used and the circumstances in which they are delivered. Separate an informational update from a request to approve an operation or acknowledge a document. Review how the version, date and intended recipient can be recognized, and whether a copy remains available for later reference. If the description relies on a legal framework for electronic records or signatures, verify the framework’s relevance to the stated entity and activity. A message arriving by email does not by itself establish its sender or authority. The document should explain how official communications can be identified and how changes to the delivery method are described.

16. Content and usage rights

16.1. Identifying the rights holder:
A service can combine software, documentation, data, fonts, artwork and trademarks from different sources. Review the ownership statement for each type of material and distinguish ownership from permission to use it. A copyright notice on a page does not necessarily cover every component shown there. Keep the relevant attribution and license information with the material it describes. Where the source or permission is unclear, an interface’s appearance alone cannot establish the right to reproduce, distribute or modify that material.

16.2. Reading a permission grant:
A license description should identify the material or service covered, the permitted actions, the users covered and any duration or conditions. Accessing an interface and redistributing its code are different activities. Read limitations together with the grant itself, including any geographic, account or transfer conditions. Record the document version supporting the permission.

16.3. Scope of permitted use:
Separate the following questions when reviewing a license:

16.3.1. Does the stated permission cover copying, modification, redistribution, display or another specific use? Identify the material and action together. A permission to view a page does not explain the terms for republishing its text, reusing an image or distributing a modified software component.

16.3.2. Does the documentation address inspection, interoperability or modification of the software? Read any condition with the applicable license and legal context rather than inferring permission from technical access.

16.3.3. Which attribution, copyright or other notices must remain associated with the material under its actual terms?

16.3.4. Are there separate permissions for a third party’s software, data, font, image or mark included in the interface?

16.4. Names and marks:
A company name, product name and logo can identify a source without granting permission to present an affiliation. Read the relevant usage terms for the specific mark and context. Distinguish a factual reference from a promotional placement or an endorsement claim. The appearance of several brands in one interface does not establish that their owners have approved the page, the service or one another. A clear rights review records the source, proposed use and applicable permission.

16.5. Feedback and contributions:
A feedback provision should explain what is being submitted and how the recipient proposes to use it. Distinguish a support report from a creative contribution, technical suggestion or public review. Read any permission relating to publication, modification or further sharing alongside its duration and conditions. A submission form should not be assumed to explain every right associated with an attached document or other material.

16.6. Separately licensed materials: Third-party components can carry their own terms and attribution requirements. Identify each material, its source and the license version that accompanies it. An application-level statement does not replace those details. Keep a distinction between a component’s code, associated artwork, bundled data and any separately distributed documentation.

16.7. Rights questions and documented responses:
When a rights concern is raised, identify the material, source and use being questioned. Keep the claim separate from any conclusion about ownership or infringement. A documented process should make clear which participant receives a report, what information is relevant and how the status of the matter is communicated. Preserve the applicable notice and version history so that the material under review can be identified accurately. Broad statements about reserved rights do not resolve an uncertain license or establish permission for a specific use.

17. Inquiries and disputed records

17.1. For an inquiry, first identify the part of the interaction at issue and the participant responsible for that part. Establish:
(a) the verified channel published by that participant; and
(b) the relevant record, time and description of the issue.

Separate the issue types: A display error, account-access problem, disputed delivery and privacy request can involve different records and recipients. The fact that several functions appear on one page does not mean one organization can resolve every issue.

17.2. A response-time statement should explain when its clock begins and what kind of response is described. An acknowledgment and a completed review are different milestones.

17.3. If a document describes a further review process, record the conditions for using it, the responsible recipient and the source of any deadline. Keep that procedure separate from general support information.

18. Responsibility and limits

18.1. A liability section should be read together with the service scope, obligations and exceptions in the same agreement. Identify the kinds of loss it discusses and the participants it names. A general limitation does not explain the cause of a specific incident or establish its legal effect. Keep factual evidence about the event separate from an interpretation of the clause. The applicable jurisdiction and circumstances matter when evaluating an operative provision; this reference guide does not determine them.

18.2. When a document groups risks, distinguish the event described in each category:
(a) A network-level change or failure, such as a change in consensus, conflicting network histories or a security incident. Identify the affected network and observed behavior instead of assuming every technical risk produces the same outcome;
(b) A change in an asset’s quoted or realized value;
(c) A delay in submission, processing or confirmation;
(d) A restriction affecting a specific account or asset;
(e) An external disruption affecting infrastructure, communications or access. The event description should identify its scope and duration separately from any claim about responsibility;
(f) An interruption at a connected provider or system. Establish which stage depended on it and what status is known for any request already in progress.

18.3. For a security incident, distinguish the observed access or action from assumptions about its cause. Relevant records can include the affected system, event time, permissions and public transaction reference. A visible failure alone does not establish responsibility.

18.4. If an operative document specifies a financial cap, read the amount, currency, calculation basis and exceptions together. Identify the claims and participants it covers. A number taken from another service’s terms has no established application to a DTCC relationship or a particular event.

18.5. The scope of a limitation can depend on the kind of claim and the legal context. Review the clause’s definitions, exclusions and any regional supplement before drawing a conclusion. A document may describe several theories or categories in one paragraph; keep those distinct from the facts of the event being reviewed and from any determination by an appropriate authority.

19. Reading dispute procedures

19.1. A dispute section should identify the parties, claims and relationships it covers. A disagreement about a merchant’s delivery can differ from a disagreement about an interface provider’s conduct. Read the scope before examining the procedure.

19.2. Informal review process:
A preliminary process should explain the recipient, required information and sequence of steps. Identify whether the stated period refers to submitting an inquiry, responding to it or attempting a resolution.

19.3. Procedure and forum:
Where a document describes arbitration or another formal process, record the named administrator, applicable rules, language, place and method of participation. Read any cost provisions and conditions alongside that description. The document should make clear which claims are included and which remain outside the process. A named forum in another provider’s agreement does not establish a forum for DTCC Trading. Questions about the effect or enforceability of an operative clause require its actual parties, circumstances and legal context.

19.4. Confidentiality scope:
Distinguish which records, communications or outcomes a procedure describes as confidential and any stated exceptions.

19.5. Court-related provisions:
Identify any statement affecting how a claim would be heard, and read its scope and applicable exceptions in context.

19.6. Individual and group claims:
If a clause distinguishes individual proceedings from collective ones, identify the claims and participants covered. Its practical effect cannot be inferred from the heading alone.

19.7. Urgent or exceptional procedures:
An exception should identify the kind of relief, issue or circumstance it concerns. Read how that exception relates to the ordinary process described elsewhere in the document.

19.8. Interdependent clauses:
A procedure may explain how one provision relates to the rest if its effect is disputed or limited.

19.9. Timing provisions:
Record what event starts a stated period, what action must occur within it and which exceptions apply. Do not transfer a deadline from an unrelated document.

20. Legal context and location

20.1. A governing-law clause and an entity’s place of establishment are separate facts. Record the stated law, scope and qualifications from the actual agreement being reviewed.

20.2. A jurisdiction or venue clause should identify the proceedings it covers and the conditions under which it applies. Distinguish the law used to interpret an agreement from the place where a matter would be heard. Cross-references to arbitration or urgent proceedings need to be read together. A location appearing in an example does not create a DTCC forum.

21. Document relationships

21.1. Included documents:
An agreement can incorporate other documents by reference. Keep an inventory of their titles, versions and scope, and identify any order of precedence. A general reference to policies is less useful than a clear way to recognize the documents involved. Compare related statements before assuming they cover the same participant or activity.

21.2. External information:
A link can provide context without making its destination part of an agreement. Identify the publisher, purpose and date of the external material. Distinguish factual references from service recommendations or affiliation claims. If a linked page changes, the statement on the referring page may no longer describe it accurately. A reader should be able to tell which organization is responsible for the information being consulted.

21.3. Changes of party:
An assignment provision should identify what could transfer, to whom and under what conditions. Distinguish a change in contract party from a change in service branding.

21.4. Treatment of past conduct:
Read any statement about the effect of earlier action or inaction alongside the right or obligation it describes.

21.5. Partial effect:
A severability provision describes the relationship between a disputed clause and the rest of a document. Its heading does not determine an individual clause’s effect.

21.6. External interruptions:
Where a document discusses events outside a participant’s control, identify the event types, affected obligations and any notice or mitigation process described. A broad list of possible disruptions is different from evidence that a particular event caused a failure. Read duration and recovery statements with the same service scope.

21.7. Formal notices:
Identify the official delivery channel, recipient and record of delivery described for each kind of notice.

22. Versions and document changes

A change section should explain how readers can identify the current version, what has changed and when the revised text is stated to apply. Distinguish the publication date from an effective date and from the date an individual encountered the document. If continued use is described as an acceptance trigger, read that statement with the service activity and notice process it references. Keep prior versions available for interpreting records from an earlier period.