Document type: service reference
Scope: terms and evidence to review
DTCC Trading focuses on Stellar tokenization and multichain interoperability. Operative service terms, a responsible legal entity and transaction arrangements are not established by this page. This reference explains the information needed to understand a service document; it does not form a contract, obtain consent or authorise a transaction.
A platform name, an asset issuer and a service provider can identify different participants. Read each role separately and connect it to the document describing that participant’s responsibilities.
Begin with the purpose and scope of the document. Identify the exact service, asset, network and jurisdiction it addresses before applying a statement to a particular situation. A technical description and a contractual commitment answer different questions.
Read associated privacy, pricing and eligibility documents in their own scope. An internal link is a way to locate information; it does not prove that the linked document is current, operative or applicable to the same service. Record the version of each source and keep unresolved differences visible.
This educational reference does not determine statutory rights or replace current official guidance for an applicable jurisdiction.
If a required term, party or process is unclear, treat it as an unresolved information gap. Do not infer an agreement from a familiar interface or a page title.
A document’s geographical scope needs an explicit source. The presence of a language option or a currency label does not confirm regional service availability, eligibility or a local contracting entity.
1. Terms and distinctions
The following review terms identify questions to resolve in a service description. They are not contractual definitions for an available DTCC transaction service.
1.1. Account: Establish whether a document refers to a website profile, a network account or a record held by a provider. These can have different owners, access controls and purposes.
1.2. Compliance context: Identify the exact legal entity, activity and jurisdiction behind a reference to verification, screening or financial-crime requirements. Read the current official source and the service’s applicable policy separately. A list of laws does not demonstrate that a process is implemented, that an entity is authorised or that a particular user is eligible.
1.3. Participant: Distinguish a reader of information from a customer entering a defined transaction. The role depends on the actual service relationship.
1.4. Conversion charge: A charge needs an amount or calculation basis, a currency and an event that makes it applicable. A conversion example does not publish a fee.
1.5. Currency: Record the exact denomination of a price or payment and whether a displayed equivalent is informational.
1.6. Funds: Distinguish fiat money, a bank balance and an on-chain asset. Each requires its own record and control arrangements.
1.7. Digital asset: Identify the token or other representation, its network and issuer, and the documentation describing what it represents. A symbol or category name is insufficient to establish rights.
1.8. Network charge: Separate a network-level charge from a service charge and identify the source used to calculate or estimate each.
1.9. Acquiring an asset: A service description should explain the requested asset, the payment route, the counterparty and the completion evidence. Read when an instruction becomes effective, what happens during a pending state and who controls funds at each stage. Do not infer an available purchase service from an educational asset reference.
1.10. Exchanging or disposing of an asset: Identify what is sent, what is expected in return and the separate networks or payment systems involved. Establish the counterparty, any validity period and the evidence for each side of the exchange. A completed step on one system does not, by itself, establish completion of the other side.
1.11. Service: Use a precise description of the activity being offered. Token issuance, asset transfer, information display and payment processing are different activities.
1.12. Destination: A payout account, a blockchain address and a hosted account identifier are different destinations. Read the required network, owner and reference information; a familiar payment-method name does not establish an integration.
1.13. Platform: An interface can present information or connect several services. Identify the participant responsible for each action instead of treating the whole interface as one legal counterparty.
1.14. Instruction: Distinguish an amount entered in a form from an authorised order or network submission. The document needs to explain the action that changes the instruction’s status.
1.15. Site: Check the source domain of the platform information.
1.16. Disposal instruction: Review the exact asset, quantity, destination and expected proceeds. The document should explain which record establishes acceptance and which establishes completion.
1.17. Price: A price needs a defined asset, quote currency, source and observation time. An indicative figure is different from an executable offer.
1.18. Transaction: Identify the event described by this term. A local request, a provider record and a validated network operation can refer to different stages.
1.19. Service charge: Read whether a charge is included in the quoted amount or applied separately, and which event determines its final value.
1.20. User: Establish whether the document addresses an individual, an organisation, an authorised representative or another role.
1.21. Wallet: Distinguish the software interface from the network account and the authority needed to sign. An address alone does not show who controls it.
1.22. Embedded interface: A component shown inside another website can involve separate operators. Read the source domain and the terms applying to the action before relying on the surrounding branding.
1.23. Geographic scope: A current eligibility document should identify the service and explain any regional conditions. An inherited country list, a locale selector or a displayed currency is not evidence of DTCC availability. Check the exact location and activity against current applicable sources; do not extend a statement about one service to another.
1.24. Reading definitions: Apply each term within the document that defines it. Similar wording in two documents does not guarantee the same scope.2. Entities and service scope
2.1. Identify the document’s intended service and audience. A statement described as global still needs an explanation of exclusions and location-specific arrangements.
2.2. Where several organisations appear, establish their roles separately. Useful identity records include:
2.2.1. The exact legal name, registration source and jurisdiction of the entity offering the specified service.
2.2.2. The asset issuer and the source describing its token or underlying-asset obligations.
2.2.3. Any party controlling funds or authorising transfers during processing.
2.2.4. Any external operator supplying payment, verification or other supporting functions.
2.3. Read legal identity and contact information together. A brand name and a physical address from different sources do not establish one responsible entity.
2.4. A claimed authorisation must match the exact organisation, activity and jurisdiction. Check current official records rather than inferring scope from an affiliate, partner or similar name. A website’s accessibility is not evidence that a particular service is available to the visitor.
2.5. Custody, dealing, payment processing and technical access describe different roles. Determine who can control an asset at every stage, who receives the payment and which participant owes any resulting obligation. A short label such as non-custodial does not explain the full processing sequence, the treatment of pending funds or the relationship between separate providers.
2.6. Availability needs a current, service-specific statement. Read any geographic, asset, account or transaction conditions together and note the source date. An educational page does not create access rights, publish a supported-region list or confirm a regulatory status.
2.7. Changes to a destination or instruction depend on the actual stage and system. Read the applicable process before assuming that a sent instruction can be edited, cancelled or recovered.3. Eligibility information
3.1. An eligibility document should make the following subjects clear:
3.1.1. The age or capacity conditions relevant to the specified service and jurisdiction.
3.1.2. The location and service scope to which any availability statement applies.
3.1.3. Whether the participant acts personally or represents an organisation.
3.1.4. The authoritative sources behind any restrictions and the procedure for resolving uncertainty.
3.2. Read the evidence required for an eligibility decision and the consequences of an incomplete review. This reference does not collect representations, set acceptance criteria or authorise an account restriction.4. Describing an activity
4.1. A clear service description separates the intended activity from the supporting interface. For example:
4.1.2. Issuing or representing an asset requires an identified issuer, network and documented rights.
4.1.3. Transferring or exchanging a representation requires a defined instruction, destination and completion record.
4.1.4. Establish the counterparty for each activity. An interface operator, an asset issuer and a payment recipient need not be the same organisation, even when their information appears in one flow.
4.2. Read control arrangements explicitly. The ability to sign, hold, freeze or redirect an asset needs to be understood in its actual service and network context.
4.3. Identify whether a wallet is supplied by the participant, hosted by a provider or accessed through another arrangement. A destination address does not explain the custody model on its own.
4.4. A payment diagram should identify the payer, recipient and processing participants separately. Review which party receives an authorisation, which records a completed charge and which supplies the asset or service. A familiar card or payment logo is not evidence of a current DTCC payment integration.
4A. Consumer-document context
4A.1. For any question about cancellation, withdrawal or another consumer remedy, identify the actual service, contracting party and applicable jurisdiction. Read current official guidance and the operative document together. This reference does not determine whether a right applies or prescribe a period for exercising it.
4A.2. An instruction to begin a service and an agreement affecting rights are different matters. Review the exact action requested and its documented effect. No waiver, consent to immediate execution or acceptance of contractual terms is obtained by this informational page.5. Access and verification documents
5.1. A permissions statement should identify what access is granted, for which purpose and under which conditions. The availability of a page does not itself grant a licence to an API, account or transaction service.
5.2. A genuine onboarding process needs an identified provider, a stated purpose and an applicable policy. This guide does not initiate verification.
5.3. Before responding to an information request, distinguish the categories involved and why each is requested:
5.3.1. Identity and contact details: establish the recipient and the purpose of each field.
5.3.2. Official identifiers: read the applicable requirement and handling notice before providing sensitive numbers.
5.3.3. Identity documents: verify the upload channel and the entity responsible for processing them.
5.3.4. Financial records: distinguish an account identifier from evidence concerning a particular transaction.
5.3.5. Device or network information: identify whether the field is observed automatically or supplied by the person.
5.3.6. Address evidence: establish which service and context require it, if any.
5.3.7. Image or biometric information: read its stated purpose, use and retention explanation separately.
5.3.8. Additional information: an open-ended request still needs a clear purpose and a verified responsible channel.
5.4. Review any role assigned to a third-party verifier and the information it receives. A provider name does not establish permission to investigate or access unrelated records.
5.5. A policy should explain how information can be corrected or updated and which event makes an update necessary. Do not infer a deadline from an unrelated document or inherited interface.
5.6. Read the process for an incomplete submission, a request for clarification and a declined application as separate outcomes. Any deadline, restriction or escalation route needs its own current source. This reference creates none of those procedures.
5.7. A compliance statement needs evidence matching the exact entity and activity. Distinguish the existence of a policy from evidence that a control operates. A request made after registration or during a transaction should still identify its purpose and the record to which it relates.
5.8. Data handling requires an applicable privacy notice covering the recipient, purpose, storage and any sharing. A verification screen does not answer all of those questions.
5.9. An access limitation needs an explained scope: account access, a pending instruction and control of an asset are different matters. Review the documented decision and contact route rather than assuming they have the same effect.6. Participation and conduct information
6.1. Read the scope of permitted access and the conditions attached to it. An informational page and an operative service agreement have different purposes.
6.2. A process that records acceptance should identify the exact document and version shown, the action taken and the effect attributed to it. A page view alone does not explain those elements.
6.3. A conduct policy needs a defined service scope and clear descriptions of prohibited activity. General references to lawful use do not replace specific, applicable requirements.
6.4. Account-security information should distinguish credentials, authorised access and recovery procedures. Review which records show account activity and how a disputed action is investigated; an account identifier does not establish who performed every action.
6.4A. Shared access: Establish whether a service permits delegated access, which roles exist and how an authorised representative is identified. Do not infer permission from the ability to share a login.
6.5. For a suspected account issue, first verify the responsible service and its contact availability. Keep the event, timestamp and relevant record together without disclosing passwords or signing secrets.
6.6. An instruction review should identify the exact asset, network, amount and destination. Read the stage at which a change becomes unavailable and the evidence establishing that stage, rather than assuming every system has the same finality.
6.7. Information requests concerning an account or transaction should identify the record under review and the responsible entity. Read the request alongside the applicable verification and privacy documents. A broad reference to compliance is not a complete explanation of the fields requested or the channel used to collect them.
6.8. Separate an asset’s documented characteristics from the suitability of a transaction for a person. This reference does not make a suitability determination or recommend an allocation.
6.9. A payment-ownership rule should explain the relationship required between the participant and the payment instrument, how that relationship is established and which exceptions or representative roles are recognised. An account name, card image or successful authorisation is not a complete description of that relationship.
6.9A. Third-party destinations: Read whether the service permits them and how authority over the destination is established.
6.10. Any allocation of loss or responsibility needs an operative clause and applicable context. No indemnity or liability transfer is created by this guide.
6.11. Statements made during a service flow need to distinguish:
(a) Location and restriction information: establish which jurisdiction, activity and person a statement concerns, and the current official source supporting it. Nationality, residence and the location of a transaction are different facts; a policy should explain which fact is relevant to its assessment.
(b) Control of an instrument or address: identify the evidence of control and whether it concerns the current instruction or a continuing relationship.
(c) Applicable obligations: identify the exact activity and jurisdiction before interpreting a legal reference. A general list of financial, tax or consumer-protection topics is not evidence that every listed framework applies to the same participant or instruction.
(d) Automated access: distinguish an authorised integration from an unsupported tool, and read the documented interface limits and permissions.
(e) Access conditions: identify the scope and source of any geographic or technical restriction.
(f) Scheduled actions: review whether scheduling is actually supported and what authorisation applies to each future instruction.
(g) Software safety: distinguish approved client behaviour from changes that interfere with another participant’s systems or records.
6.12. A clarification process should identify what changed, which earlier statement it relates to and how a corrected record is handled. An update request needs a verified source.
6.13. Further evidence to distinguish:
(a) Ownership and source: a payment instrument’s owner and the origin of a particular amount are separate questions.
(b) Third-party rights: identify the asset, content or instruction concerned before interpreting a permissions statement.
(c) Information sharing: read the recipient, purpose and categories of information together. A possible reporting obligation does not establish unrestricted sharing with every party in a service flow.
6.13A. Embedded interfaces and information flows
When a feature appears within another website or application, establish the role of the host page and the operator of the embedded component separately. The visible location of a form does not explain where its information is sent.
(a) Entry point: identify which interface creates the request and which service receives it.
(b) Shared information: a flow description should distinguish the following categories rather than treating them as one record:
(i) Verification results: separate a status response from underlying documents or identification data.
(ii) Payment references: distinguish a transaction token from the full payment credentials it may represent.
(c) Purpose and scope: identify which information is necessary for the particular interaction and the participant using it.
(d) Subsequent handling: read each recipient’s applicable notice for use, storage and onward sharing. A statement by the host page is not a complete account of another operator’s practices.
A request to share information needs a clear description of the proposed action and its effect. This reference records no consent to a third-party transfer.
A technical connection should remain distinguishable from an authorisation to use the connected information for another purpose.
6.14. Read responsibilities in relation to the specific role and activity. A general responsibility statement should not obscure which participant controls each step.
6.15. A permitted-use description can distinguish these subjects:
(a) Service impact: identify limits protecting availability and the behaviour considered disruptive, with a scope tied to the actual interface.
(b) Purpose restrictions: read the activity definitions and applicable policy rather than inferring permission from a successful technical request.
(c) Programmatic access: establish the approved endpoint, rate conditions and data-use permissions before interpreting an integration example.
(d) Identity and authority: distinguish an authorised representative from an unrelated account user, and provide a route for correcting inaccurate records.
(e) Restricted features: identify the permission boundary and the process for legitimate access requests.
(f) Harmful content: distinguish a service’s safety controls from a guarantee that every uploaded or linked resource is safe.
(g) Connected applications: read the scope granted to each application and the method for reviewing or withdrawing its access.
(h) Participant behaviour: a conduct policy should explain the relevant action and consequences without relying on vague catch-all labels.7. Provider roles and decision processes
7.1. A review or restriction process should distinguish a request that has not been accepted, a pending transfer and an asset already controlled by another party. Read the grounds, scope and record of a decision together. This page grants no authority to hold funds, refuse an instruction or block an account.
7.2. A service commitment needs a defined action and completion standard. Submitting an instruction, monitoring its status and guaranteeing its result are different commitments; identify which is actually stated.
7.3. Read the evidence for submission, network acceptance and receipt separately. A reference number can identify an attempted operation without establishing every downstream outcome.
7.4. Responsibility for an incident depends on the applicable documents and context. Identify the event, the participant’s role and the alleged consequence before interpreting any limitation or exception. This reference determines no allocation of liability.
7.5. An interruption description should identify the affected dependency and the stage of processing. A local interface failure and an external network delay can require different evidence.
7.6. A reporting or escalation statement needs an identified recipient, purpose and relevant policy. Do not infer an unlimited information-sharing arrangement from the possibility of a transaction review.
7.7. Read any stated exceptions to a responsibility clause in the same operative document. A short summary is not a determination of mandatory legal protections.
7A. Restrictions and authoritative records
7A.1. Establish the exact activity, participant and jurisdiction behind any sanctions or trade-control reference. Use the relevant official source and its current scope rather than a copied country list.
7A.2. Distinguish the location of a person, their residence, their nationality and the source or destination of an instruction. A restriction can address a specific relationship; these facts should not be treated as interchangeable.
7A.3. Read how a service identifies the applicable restrictions and resolves uncertain matches. A broad compliance statement does not describe the procedure.
7A.4. An action taken during a restriction review needs a stated scope and contact route. Account access, instruction processing and control of an asset remain separate subjects.8. Completion, exceptions and return processes
8.1. Define completion for every part of a flow. A payment authorisation, a completed charge, a submitted blockchain operation and a recorded receipt can occur at different times. The relevant document should identify the event used for each status and the evidence supporting it. A transaction identifier alone does not establish all contractual or network outcomes.
8.2. A return or exception process should describe distinct cases, including:
8.2.1. An asset or network that differs from the instruction’s stated requirements.
8.2.2. An amount that does not match the accepted instruction or its applicable limits.
8.2.3. A request that cannot proceed because a review or technical step remains incomplete.
8.3. If a return process involves costs, the document should distinguish:
8.3.1. A network charge associated with a specific attempted or completed operation.
8.3.2. A charge imposed by a separate payment or service participant.
8.3.3. A stated administrative charge, including its basis and the event making it applicable.
8.4. A restricted-party review needs current evidence and a defined process. Identify the participant, asset or instruction being reviewed and the source of the relevant restriction. Read the resulting decision in its own scope instead of assuming that every review leads to the same action.
8.4.1. Status: establish whether the instruction is pending, declined or subject to another documented state.
8.4.2. Authority: separate the official source of a restriction from the service participant applying its policy. Relevant source records can include:
• The exact issuing body and the subject covered by its record.
• The current version and effective scope of the cited measure.
• Identifiers used to distinguish one person or organisation from another.
• Geographic or activity conditions relevant to the instruction.
• Exceptions or review procedures described in the official source.
• The service policy connecting that source with a particular decision.
• The date of the review and the evidence supporting its conclusion.
8.5. A proposed return needs its own destination, asset and authorisation details. It should not be assumed to reverse the original operation automatically.
8.5.1. Destination review: verify the intended recipient and network through the applicable service process.
8.5.2. Recoverability: read the technical and cost constraints stated for the particular case. An example cannot guarantee recovery or establish an entitlement to a refund.9. Instruction limits and discrepancies
9.1. Amount conditions
9.1.1. A minimum or maximum needs a denomination, service scope and effective source. Review whether the condition applies before charges, after charges or to a converted equivalent. The document should distinguish rejecting an instruction from receiving an unintended transfer; the latter can involve separate technical and return questions. No DTCC order threshold is published by this reference.
9.2. Asset and amount mismatches
9.2.1. Different asset: establish the exact identifier and network actually received rather than relying on its displayed symbol.
9.2.2. Different amount: compare the authorised quantity with the relevant records and identify whether charges or unit conventions explain the difference.
9.2.3. Unknown representation: determine whether the recipient can identify and control it. A visible balance does not prove recoverability.
9.3. Conditions on new instructions
9.3.1. A service-limit statement should explain the affected action, the relevant participant and how the condition is communicated. Read location, asset, amount and account conditions separately. An accessible interface does not establish that an instruction will be accepted.
9.4. Reviewing an intended instruction
9.4.1. Check the record’s asset identifier, network, quantity, destination and any required reference as one coherent instruction.
9.4.2. Distinguish a preview from the exact payload or order being authorised; a summary should accurately describe its scope.
9.4.3. Read the point at which cancellation or editing ceases to be available. Do not assume that an interface button changes an already completed operation on another system.
9.5. Access and authority
9.5.1. A security policy should distinguish possession of credentials from the authority to act. Read the account’s access controls, recovery arrangements and activity records together.
9.5.2. A sign-in or signature record needs context; it should not automatically settle every question about an instruction’s authorisation.
9.6. Disputed instructions
9.6.1. The applicable process should explain the evidence reviewed, the participant handling the issue and the route for clarification. This guide assigns no loss or liability.
9.7. Incident communication
9.7.1. A notice about an incident should identify the affected service, known information and recommended next steps through a verified channel. Distinguish confirmed facts from an investigation still in progress. This reference promises no notification period or response procedure.10. Prices, charges and payment roles
10.1. Cost presentation: read the quoted amount, currency, individual charges and expected resulting amount together. A visible number without those definitions is not a complete price.
10.1A. Applicable context: a payment process needs a defined provider and service scope before a regulatory claim can be assessed.
10.2A. Display units: distinguish the charged currency from any informational equivalent and record the conversion source and time.
10.2. Payment recipient: identify which legal entity appears on the payment record and what service it supplies. A merchant descriptor, a processing provider and an asset issuer can represent different roles. Read the documents connecting those roles before attributing a charge or a delivery obligation to a brand shown in the interface.
10.3. Authorisation scope: an actual payment request should explain the amount, recipient and permitted action. Distinguish authorising a charge from authorising a later adjustment or return. This educational document does not grant permission to debit, credit or alter a payment instrument.
10.4. External payment terms: a payment instrument can involve a separate provider’s terms. Identify the relevant account and service before interpreting rules concerning authorisation, disputes or processing.
10.5. Separate provider costs: identify which participant imposes each charge and whether it is included in the displayed amount. A single label such as processing fee can hide several different bases.
10.5.1. Variable charges: read the input, calculation method and point at which the amount becomes fixed. A charge depending on another system needs a current source and an explanation of any estimate.
10.6. Fee information: use the pricing reference to understand the fields that a fee schedule needs. Compare the document version and applicable service; an educational example does not create a payable charge.
10.6A. Network costs: distinguish the network’s charge mechanism from a service provider’s fee. A useful explanation identifies the asset used for the charge, the units, the observation source and the event that determines the final amount. A quoted estimate should remain distinguishable from a recorded cost after processing.
10.7. Payment sequence: read which event represents authorisation, capture and delivery. Their order needs a current service definition and evidence for each step.
10.8. Funding conditions: distinguish the amount required for the intended instruction from charges or limits imposed by a separate bank or payment provider. The applicable documents should explain which participant controls each condition.
10.9. An exception decision should identify the request affected and its current state. Refusing a new request, pausing processing and reversing a completed payment are different actions and may involve different participants.
10.10. Return authority: any actual refund or reversal process needs a defined party, destination and scope. It should not be inferred from a general payment authorisation.
10.11. Transaction records: a useful record identifies the asset and amount, currency, charges, recipient, status and relevant references. Compare records from each system when a flow spans a payment service and a blockchain network.
10A. Reading transaction states
10A.1. Identify the action offered by the actual service. A form presenting an asset pair is not proof that a purchase or sale is enabled.
10A.2. Timing: define the start and end events behind a processing-time statement. An interface response, a review result, a network submission and a confirmed receipt can measure different intervals. Read which conditions affect the interval and whether the statement is an observation, an estimate or a service commitment. A reference number can help locate a record without proving completion. Where several systems participate, examine each status separately and reconcile their timestamps instead of treating one fast response as evidence for the entire flow.
10A.3. Status changes: a document should identify the point at which an instruction becomes effective and how that event is evidenced. Submission, execution and finality should not be treated as synonyms without an explanation of the system involved.
10A.4. Delays: determine whether the pending step concerns a provider review, a network operation or a destination system. The appropriate record and contact route depend on that stage.
10A.5. For an unfamiliar instruction, preserve the relevant record and review contact availability before sending information to a purported support channel. This guide does not establish an account-freezing or investigation procedure.
10A.6. A recall or cancellation request is different from a completed reversal. Read which system receives the request and which record confirms its outcome.
10A.7. A discrepancy should be evaluated against the authorised instruction and the records showing what occurred. Identify the asset, units, charges and relevant time before attributing a difference to an error. A request to send an amount back needs an independently verified source and a defined correction process; this reference creates no recovery mandate.
10B. Changing values and processing time
10B.1. A fee schedule should identify its version, calculation basis and scope. Establish which version applies to the actual instruction.
10B.2. External costs and rates need their own source. Do not attribute a separate provider’s charge to the interface operator without evidence.
10B.3. The event that makes a charge applicable should be clear. A preliminary estimate does not itself establish a payment obligation.
10B.4. Processing-time evidence should distinguish time spent before submission from time spent awaiting a downstream result. A single elapsed total can obscure that difference.
10B.5. A revised quote needs a clear relationship to the earlier quote, including the changed inputs, validity conditions and any fresh authorisation required. An automatically refreshed display is not necessarily an accepted revised instruction.
10B.6. Read any statement allocating the consequences of delay or a changed value in the operative agreement. This reference records no acceptance of a price change and imposes no waiver of rights.
10C. Units and rounding
10C.1. A calculation rule needs the asset or currency, supported precision, rounding direction and the stage at which rounding occurs. Compare the displayed amount with the recorded amount; a formatted value can hide precision without changing the underlying quantity.
11. Reading asset and operational risks
11.1. A risk review should distinguish the following subjects:
11.1.1. Value changes: identify the source and time behind a quoted value and consider that a later observation can differ substantially.
11.1.2. Rights and backing: read the exact asset and issuer documents. A token category does not establish redemption rights, government backing or an insurance arrangement.
11.1.3. Market conditions: distinguish an observed price from available liquidity and the ability to complete a particular instruction.
11.1.4. Network outcomes: read the relevant network’s definition of acceptance and finality rather than treating all blockchain operations identically.
11.1.5. Dependencies: identify the wallets, connectivity and external services involved, including the record each provides for its stage.
11.1.6. Regulatory context: connect an official development to the exact asset, activity and jurisdiction before interpreting its effect.
11.1.7. Protection claims: an insurance or compensation statement needs an identified provider, covered event, exclusions and current evidence. Do not infer coverage from a familiar asset, a bank-related term or a platform’s appearance. An educational reference establishes no DTCC insurance or compensation arrangement.
11.1.8. Acceptance: the ability to hold or transfer a representation does not establish that another party will accept it as payment or exchange it on particular terms.
11.1.9. Destination errors: identify the network, address and required reference before interpreting a transfer record. A technical ability to send does not ensure that the intended recipient can recognise or recover the asset. Read the specific recovery constraints rather than assuming reversibility.
11.1.10. Timing: distinguish when an instruction was created, submitted, observed and completed. Records from separate systems may use different timestamps.
11.1.11. Technical change: evaluate protocol changes, faults and security incidents in the context of the exact network and software involved. A general technology label is not a security assessment.
11.1.12. Market continuity: a previous trading observation does not establish that a venue, counterparty or source will remain available for a future instruction.
11.1.13. Changes in access: read current service conditions alongside relevant official developments. A rule concerning one activity should not be extended automatically to every use of an asset.
11.1.14. Educational scope: an explanation of a token or network is different from a recommendation to acquire, hold or dispose of it. Review the sources, assumptions and unresolved questions behind the explanation. This page does not determine an asset’s suitability or provide a forecast.
11.1.15. Operational access: distinguish a failure to display information from a failure of the underlying network or asset. Identify the affected component before drawing a conclusion about the status of a record.
11.2. A risk description does not, by itself, allocate legal responsibility for a loss. Read any allocation in the applicable operative agreement and context.
11.3. Distinguish general information from advice directed to a person’s circumstances. The source and intended audience matter.
11.3.1. Tax-document context
A tax question needs the specific person, activity, asset and jurisdiction, together with current authoritative information. A transaction record can supply facts without determining their legal treatment. This reference provides no tax calculation, reporting service or allocation of tax responsibility.
12. Service descriptions and assurance claims
12.1. Read what an assurance actually covers: a feature, an information source, an availability period or a transaction outcome can be different subjects.
12.2. A warranty or disclaimer belongs to an operative document with identified parties and scope. This guide creates neither a warranty nor a waiver, and does not determine the effect of any legal limitation.
12.3. A reliability claim needs evidence matching the service, version and time period being described. A successful demonstration is not proof of uninterrupted operation.
12.3.1. Assess each type of claim separately:
(a) Access: which interface or service is covered and over which period?
(b) Compatibility: which network, wallet, device and configuration were actually considered?
(c) Information quality: what source, observation time and method support a displayed price or other value?
(d) Continuing support: which asset, currency or payment capability is covered by a current service statement?
12.4. Compare the source record with the claim being made. Accuracy, completeness and freshness are separate properties; a correct historical figure may still be unsuitable as a current quote.
12.5. Establish the intended beneficiary and the specific promise in any assurance document. A statement addressed to one participant should not be assumed to confer rights on every reader.
12.6. Maintenance information should identify the affected feature, timing and treatment of pending work. This reference makes no availability commitment.
13. Control and custody questions
13.1. Determine who can authorise movement, restrict access or recover an asset at each stage. A custody label is a starting point for this review, not a complete description of the account structure, legal relationship or technical controls.
13.2. Read where a payment remains before an instruction completes, who controls it and which record shows that state. Temporary processing and a continuing account balance need to be distinguished.
13.2A. For a flow exchanging one representation for another, follow both sides separately. Identify the recipient of the first asset, the source of the second and the event connecting their delivery obligations. A statement about inventory or a processing interval does not, by itself, resolve every custody question.
13.3. Delivery evidence should identify the exact network destination and the asset or amount recorded there.
13.4. Destination control and compatibility are separate checks. An accessible address does not necessarily support every asset or network.
13.5. A custody or wallet document should distinguish problems involving:
13.5.1. An unintended or incorrectly entered destination.
13.5.2. Loss of the authority needed to access or sign for an account.
13.5.3. A mismatch between the receiving software, asset and network.
13A. Security procedures and verified channels
13A.1. Review the actual access, backup and recovery arrangements for the relevant account or wallet. Different services can use different authorities and recovery mechanisms.
13A.2. For a suspected access issue, verify the service’s contact availability before sharing information about the event. Keep signing secrets out of a support exchange.
13A.3. A request for a password, private key or recovery phrase is not justified by a support label. Verify the channel and the purpose of any information request.
13A.4. Read the applicable incident procedure and preserve relevant records; this guide imposes no reporting deadline or liability rule.
13B. Electronic records and notices
13B.1. A notice process should identify the document, recipient, delivery channel and event treated as delivery. A website update, an email and an account message can have different scopes. Read how versions are identified and how a participant can obtain a record of what was presented. This page does not obtain consent to electronic communications or signatures.
13B.2. A communication preference needs to distinguish service notices from other messages. Read the applicable process through contact information and establish which setting is being changed. An unsubscribe action for one message category does not explain every channel or account consequence.
13B.3. For a question about the legal effect of an electronic notice or signature, identify the action, record and applicable jurisdiction. A technical acknowledgement and a legally effective acceptance should not be treated as interchangeable without the relevant context.
14. Reading a permitted-use policy
14.1. A permitted-use policy should define its scope and explain the activities it addresses. The following categories identify information to look for; they do not create DTCC account rules:
(a) Applicable restrictions: identify the specific activity, jurisdiction and authoritative source behind a prohibition. A general reference to legality does not explain how the service assesses a particular instruction or resolves uncertainty.
(b) System impact: distinguish unauthorised access, disruptive load and misuse of an interface. Each description should identify the boundary affected and the approved route for legitimate access.
(c) Other participants: a policy should explain how it addresses interference with privacy, safety or rights and where concerns can be raised through a verified channel.
(d) Accuracy and deception: identify which statements or records are relied upon and the process for correcting inaccurate information.
(e) Restricted activities: a category needs a clear definition and applicable scope; a broad label alone is not a complete eligibility rule.
(f) Content permissions: distinguish a participant’s original material from third-party works, marks or other protected material.
(g) Restricted goods or services: read the actual list, definitions and source date in the applicable policy. A copied example list does not establish a current DTCC restriction or authorise an otherwise unsupported activity.
(h) Financial-service claims: identify the provider, activity and evidence behind a claimed authorisation. A promotional statement is not a substitute for an authoritative record.
14.2. A decision based on a use policy should identify the affected action, the reason and the available clarification process. This reference does not grant enforcement powers or create a termination procedure.
14A. Account closure and pending work
14A.1. Read how closure relates to unfinished instructions, access to records and any continuing service relationship.
14A.2. Distinguish voluntary closure from a temporary restriction or a provider-initiated termination; each needs its own stated process.
14A.3. An inactivity rule needs a defined event and period. An unused interface does not necessarily mean that every associated record is inactive.
14A.4. Read how closure affects earlier obligations in the actual agreement; this guide creates no surviving charge or entitlement.
14A.5. A pending return may involve a separate provider and status record. Closing an account does not itself establish that the return completed.
15. Content, software and permissions
15.1. Ownership evidence: identify the creator or rights holder for each category of material, including software, text, images and branding. A site’s possession or display of an item does not prove that it owns every right to that item. Read licence notices and source records in their own scope; this reference makes no blanket DTCC ownership assertion.
15.2. Permitted use: a licence should state the relevant material, permitted actions and conditions. Accessing a file, inspecting code and redistributing an asset are different actions and may require different permissions. Do not infer permission from the absence of a technical download restriction.
15.3. Brand references: distinguish identifying a product from using its mark as your own identity. Read the applicable brand guidance and permission record for the intended use. The appearance of a third-party mark in preserved material does not establish a partnership, endorsement or transfer of rights.
15.4. Submitted content: establish who owns the material and which specific permissions are proposed for storage, display, modification or distribution. A submission flow should explain its scope before attributing a licence to a user action. This guide obtains no rights in user content.
15.5. Feedback: a suggestion and a licence to exploit associated material are different matters. Read any proposed feedback terms and the rights they cover. No perpetual, transferable or commercial permission is created by this reference.
15.6. Third-party material: identify the relevant licence or permission for each dependency and asset. A package’s licence may not cover a surrounding composition, font or trademark. Keep the source and permitted use connected to the actual material.
15.7. A rights concern should identify the material, source and claimed interest. Review contact availability before sending a notice; a generic support label does not identify a designated legal recipient.
15.8. A process for reviewing a rights concern should distinguish receiving a notice from deciding the issue or taking action. The applicable operator and procedure need to be identified.
15.9. A permission statement should make its limits clear. This informational page grants no licence or transfer of ownership.
16. Personal-information documents
16.1. Begin with the responsible entity, processing activity and categories of information. A privacy statement needs to describe the service actually involved rather than relying on a general commitment alone.
16.2. Read the stated purpose and legal explanation for each processing activity separately. An activity supporting a service, satisfying a requirement or relying on a choice can raise different questions. This reference establishes no DTCC processing basis or policy.
16.3. Request information to locate
A current notice should explain how to ask about:
(a) The information and activity associated with a particular record.
(b) Correcting an inaccurate field or requesting removal in the applicable context.
(c) A proposed change to the purpose or manner of processing.
(d) Obtaining a usable copy of relevant information where applicable.
(e) A previously recorded choice and the effect of changing it; and
(f) The appropriate official route for an unresolved privacy concern.
16.4. Retention: identify the record category, purpose and event that starts or ends a period. A single number does not explain every copy or associated record. Read any stated exceptions and the treatment of information after a service relationship ends; no fixed DTCC retention period is established here.
16.5. Review evidence: distinguish a policy, an assessment of a proposed activity and evidence from an implemented control. Each answers a different question.
16.6. Cross-border handling: identify the recipient, locations and activity involved. Read the exact contractual and official sources supporting any safeguard claim. A provider’s headquarters alone does not describe every place where information can be stored or accessed.
16.7. Read the applicable privacy document in full, including its service scope, version and links to more specific notices.
16.8. Before raising a request, identify the responsible entity and check privacy-contact availability.
17. Questions, complaints and external routes
17.1. A complaint procedure should identify the responsible entity and distinguish its channels, including:
17.1.1. A verified complaint-contact status for the specific service; and
17.1.2. The current status of any
help-centre reference
17.2. Read whether a stated period concerns acknowledgement, an initial response or a final decision. A published aim and a binding deadline are different statements; this guide establishes neither for DTCC.
17.3. Escalation and current external information
Identify the jurisdiction, service and subject before selecting an external route. The former European Online Dispute Resolution platform was discontinued on 20 July 2025. Its old entry point should be read as a historical European Commission reference.
A current escalation notice should identify the organisation handling the issue, its scope and the procedure that is actually available. Preserve the relevant service record and correspondence, and distinguish an external information resource from a body authorised to decide a particular dispute.18. Understanding responsibility clauses
18.1. A responsibility clause needs identified parties, a defined event and an applicable agreement. Read the categories of consequences it discusses separately, such as:
18.1.1. An indirect consequence: establish how the claimed consequence relates to the original event and the scope of the clause.
18.1.2. A business or opportunity claim: identify the evidence and the period to which it relates.
18.1.3. A record or information issue: distinguish loss of access, alteration and permanent loss.
18.1.4. An external claim: identify the third party, subject and relationship to the service being reviewed.
18.1.5. A technical or instruction issue: distinguish the following causes:
(a) Information entered in an instruction, including its destination and units.
(b) The state and operation of the network processing the instruction.
(c) The authority required to access or sign for a wallet or account.
(d) A restriction affecting the participant, service or processing stage.
18.2. A monetary limit needs a stated amount or formula, denomination and scope. Read which event it covers and which exceptions are described in the actual agreement.
18.3. An aggregate limit and a limit for one event answer different questions. Identify the period, transactions and parties included in each before comparing them.
18.4. A clause’s legal effect depends on its applicable context. This reference does not determine enforceability, select a legal theory or allocate liability for any event.
18.5. Read any mandatory protections and exceptions in current authoritative guidance relevant to the situation, alongside the operative document.
18A. Reading reimbursement and defence provisions
A provision concerning reimbursement, defence or third-party claims should identify the parties, triggering event, costs and procedure it covers. These subjects differ from the price of a service or the cost of a network operation. Read the conditions and exceptions together before interpreting the effect of such a provision. This informational page creates no indemnity or obligation to fund another party’s defence.
(a) Use of a service: identify the particular action and the relationship it has to the claim.
(b) An alleged breach: identify the operative provision and the conduct said to fall within it.
(c) An information issue: establish which statement was relied upon and how it affected the event.
(d) Another party’s rights: identify the material, asset or activity and the right being asserted.
(e) Delegated or disputed access: distinguish the account record from evidence of authority to act.
An exception or survival clause needs the same careful scope review as the main provision. Identify the event, period and parties it addresses, and distinguish the continuation of a stated obligation from the continuation of account access. This reference determines neither the effect of an exception nor a duty surviving closure.
18B. Asset-specific responsibility questions
18B.1. Form of a proposed remedy: distinguish delivery of an asset, a money payment and another action. The applicable document should identify the requested result and its basis.
18B.2. Valuation: a calculation needs an exact asset, quote currency, source, time or period, and method. A chosen observation can materially affect a result; its selection needs an explanation.
18B.3. External events: a description should distinguish the cause, the affected dependency and the resulting service impact. Examples of subjects to separate include:
(a) Network behaviour: a protocol change, competing history, security incident or software fault can affect different parts of a system. Identify the specific network and evidence rather than treating every blockchain event as equivalent.
(b) Market movement: a change in observed value is different from an operational failure.
(c) Official action: establish the exact measure, activity and jurisdiction involved.
(d) Wider disruption: identify the interruption, its timing and its connection to the service outcome being discussed.
(e) External dependencies: establish which provider or system was unavailable and what that prevented the service from doing.
18B.4. A proposed cap needs a complete formula and scope. An amount in one currency, a fee-based measure and a time-window condition are separate inputs. This guide states no DTCC liability cap or applicable calculation.
18B.5. An exclusion of consequences needs to be read with its definitions and exceptions. A familiar legal label does not explain every category of loss or establish the effect of a clause in a particular jurisdiction.
18B.6. Mandatory protections: use current authoritative guidance to understand the applicable context. An informational summary cannot settle which protections apply to a person, activity or loss, and this reference does not ask a reader to waive any rights.
18B.7. Scope and validity: distinguish the intended scope of a provision from whether it can take effect in the relevant circumstances. A document’s wording alone is not an adjudication of that question; read any related provisions and applicable official sources together.
18C. Consumer-document review
For a consumer-related question, first establish the actual service, participant and jurisdiction. A general industry category does not resolve the applicable relationship. Documents and official guidance may address distinct subjects, including:
18C.1. The description and standard of the service actually agreed.
18C.2. The available procedure for an alleged failure or discrepancy.
18C.3. Whether a cancellation or withdrawal question arises in that context.
18C.4. Any stated exceptions or mandatory protections relevant to responsibility.
18C.5. The appropriate official source or body for understanding a possible redress route.
These are topics for locating current information, not a determination of a reader’s rights or a list of remedies offered by DTCC Trading.
19. Reading a dispute procedure
19.1. Initial contact: a procedure should identify the recipient, the information needed to understand the concern and the record of the response. General contact details and a formal notice channel may differ.
19.2. Formal procedure and participant scope
Where a document proposes a formal dispute mechanism, identify the institution, rules, location, language and parties to which it applies. Read any consumer or other exceptions in the same context. This page selects no arbitral institution, creates no arbitration agreement and does not require a reader to surrender access to another remedy.
19.3. Jurisdiction-specific questions
A dispute procedure should make its intended geographic and participant scope clear. Read the relationship between the contractual wording and current official guidance applicable to the situation. The language of a website or the name of an affiliate does not, by itself, identify the proper forum or governing rules.
19.4. Individual and group procedures
A document should distinguish an individual concern from a collective or representative process. This reference limits no participation rights and determines no available procedure.
19.5. Time-sensitive concerns
Identify the nature of an urgent concern and the relevant official process. A general service contact form should not be assumed to provide every form of urgent legal or technical assistance.
19.6. Related provisions
Read a dispute clause with the other sections it references. An isolated sentence may omit definitions, exceptions or conditions needed to understand its intended scope.
20. Law, location and source records
20.1. A governing-law statement needs an operative agreement and identified parties. This educational reference selects no governing law and does not determine which mandatory rules apply to a situation.
20.2. A general document cannot resolve every local requirement. Use the exact service and participant context when reading official guidance.
20.3. A venue statement needs to identify the proposed forum and any applicable exceptions. A postal address or company registration alone does not establish where every dispute must be heard.
20.4. Treat the former ODR entry point as a historical source and verify current consumer-redress information through the European Commission reference.
21. Document structure and related material
21.1. Complete document set: identify the versions of the main terms and every incorporated policy. A list of links does not establish that the documents address the same service or period.
21.2. External material: identify the source, author and purpose of a third-party page or component. A link can provide evidence or a separate service without making its contents part of an agreement. Read any permission, service and privacy documents that apply to the external material in their own scope. A reference in this guide does not endorse that provider, establish a commercial relationship or transfer responsibility for its statements to DTCC Trading.
21.3. Transfer of a role: a document should distinguish assigning a contractual position from moving an asset, changing a service provider or transferring information.
21.4. Enforcement history: an earlier response or lack of response does not explain every future consequence; read the actual provision and context.
21.5. Document dependencies: note which sections rely on shared definitions or exceptions. Removing one statement can affect how another is read.
21.6. Disruption clauses: identify the event, affected obligation and stated process rather than assuming that every external failure has the same contractual effect.
21.7. Notices: identify the recipient, channel, document version and event treated as delivery. A routine message and a formal notice can serve different purposes.
21.8. Confidential information: a provision should define the information, permitted use, recipients and duration of any proposed restriction. Distinguish protecting a record from assigning ownership of it. Read how authorised disclosures, legal requirements and return or deletion are addressed. A confidentiality label alone does not explain all of those matters, and this guide creates no non-disclosure obligation.
21.9. Relationships: establish whether a person acts as an employee, representative, service provider or independent participant in the actual arrangement. A technical integration, co-branded appearance or shared asset reference does not prove an agency, partnership or power to bind another organisation.
22. Versions and amendments
22.1. A change notice should identify the old and new versions, the subjects changed and the relevant dates. Read how the change is communicated and whether any further action is required. Publication, effectiveness and acceptance are different events; this guide establishes no amendment process or automatic acceptance rule for DTCC services.
23. Finding applicable official information
A regulatory reference needs an exact entity, activity and jurisdiction. The following categories describe how to organise source research without claiming that DTCC holds an authorisation or implements a listed compliance framework. Distinguish legislation, regulator guidance, an entity-specific register entry and a service’s own policy; each provides different evidence.
23.1. Identify the activity and location
Source questions:
Which jurisdiction is relevant to the specific participant and service?
Which activity is being described, and how does the official source define it?
Does a cross-border element introduce a separate scope that needs review?
Which current restrictions or official notices address that exact context?
Records to distinguish:
The official body responsible for the activity being researched.
The source explaining that body’s remit and current procedures.
Any separate authority responsible for a restriction or reporting topic.
23.2. Establish the current source version
Version questions:
What is the date and status of the applicable official document?
Does the text include amendments or point to a consolidated version?
Are there transitional provisions or scope conditions to read?
Does another related instrument address a different part of the activity?
Evidence fields to record:
The official title, publisher and stable identifier of the source.
The activity and jurisdiction to which the passage applies.
The date on which the source was reviewed.
Any unresolved question about its relevance to the service.
23.3. Check entity-specific claims
Identity questions:
Does the legal name match the exact organisation making the claim?
What activity and scope does the authoritative entry describe?
Is the record current, conditional, limited or subject to another notice?
Does a claim about an affiliate actually cover the service being considered?
Cross-checks to retain:
The entity identifier used by the official record.
The service description explaining the organisation’s role.
The source of any limitation, exception or status change.
23.4. Relate policy to implementation
Operational questions:
Which documented procedure addresses the activity under review?
What evidence shows the control operating in its stated scope?
Which gaps remain between the policy, technical behaviour and public claim?
Review outcomes:
Confirmed facts supported by a source matching the claim.
Open questions requiring further evidence or clarification.
Claims whose scope is broader than the available record.
23.5. Maintain an identifiable document history
Keep source dates and unresolved questions connected to each review. A later change should be traceable to the document or evidence that changed. For the status of a DTCC information channel, read contact availability.