Data transition notes

Data transition notes

1. Purpose and scope of a transition notice

These notes explain how to read a proposed data transition. DTCC Trading has not published an operative migration notice on this page; no transfer, recipient or request for consent is established here.


Start by identifying the event described in the document. A change of contact details, a change of service provider and the movement of customer records are different subjects. Record which event the notice addresses, who issued it and the document version being reviewed. Keep a proposed change separate from an action already evidenced by a dated record.


A useful review connects the purpose of a proposed change with its participants, the information involved and the decision being requested. Read the full explanation before interpreting a heading or a button label. Identify which activities are included, which remain outside the notice and where further terms are referenced. If a document combines an account change, identity review and communication preferences, assess each part separately so that one description does not stand in for the others. Note who would receive a decision and what record would identify its scope.


2. Participants and responsibilities

Identify the roles described in the proposal:


  • Sending party: identify the exact entity that would supply the records, the account or service in scope and the source explaining its responsibility for the proposed action.

  • Receiving party: identify the exact entity that would receive the records, the stated purpose of receipt and the document describing how that entity would use the information.


Read each participant’s role in the applicable documents. Shared branding or a common technical provider does not establish responsibility. Check who handles questions at each stage and whether the cited notice describes that same role.


3. Information included in the scope

List the actual categories named in the notice. Distinguish records described as already held by a recipient from information a proposal would newly provide. Record the evidence for that distinction; a general account description is not a data inventory.


For each category, note its description, source, recipient and purpose. If the notice names a technical transfer method, check which records it is said to copy and which account boundaries it crosses. The categories below illustrate separate review questions:


  • Identity records: check the named document types and identifiers without copying personal data.

  • Address evidence: distinguish records from verification status.

  • Image-based checks: separate images and verification results.


Financial and transaction information needs its own scope description. Check whether a proposal names balances, payment details, activity history or other records, and whether it explains any conditions affecting their inclusion. A reference to identity verification is not a substitute for that inventory. Keep exclusions and unresolved scope questions next to the categories they concern.


For images or biometric verification, read the described inputs, outputs and uses separately. Ask whether a notice concerns an original image, a verification result or another derived record. Compare the stated purpose with the permissions and handling information cited for that category. Similar labels can describe different processes, so preserve the source’s exact wording.


4. Purpose and reuse of existing records

Connect each proposed use to the records said to support it. Reusing a record and conducting a new review are different steps. Check the described age, completeness and suitability of prior information and whether further checks form part of the process. Record the conditions for any stated outcome instead of treating a copied file as proof that an account has been activated.


5. Basis, permissions and decision scope

Identify the stated basis for each processing activity and its supporting document. Review the proposed sending action, the recipient’s later use and any continuing activity by the original service separately. A heading about permission does not resolve every activity’s scope.


If a notice describes an earlier disclosure, record its purpose, categories and timing separately from a new proposal. Identify which explanation belongs to each event. Past activity should not be read as a request to approve a different action, and a proposal should not be recorded as completed.


Compare the proposal with the documents governing the existing service. Identify which purposes or responsibilities are described as continuing and which would change. Follow policy references before deciding how the documents fit together. Keep conflicts between versions visible instead of choosing whichever wording seems convenient.


Read the stated choices and their consequences before recording a decision about a proposal.


6. Locations and onward handling

Check the stated locations and roles for storage, access and onward handling. One organization’s address does not describe every part of a process; keep each location tied to its source.


7. Retention and deletion information

Look for the retention rule applicable to each category of information and the event from which a stated period is measured. Distinguish continued use, restricted storage and deletion where the documents do so. Review any described exceptions alongside the main rule, including how overlapping records are handled by separate participants. A period quoted without its category, starting event or conditions is incomplete review information.


8. Alternatives and continuity of service

Read the stated effects of accepting, declining or deferring a change. Distinguish account access, verification, communications and the handling of existing records. Check whether an alternative requires another process and which documents govern it. Do not assume that every choice has the same effect on every activity.


Any date in a transition document needs a defined event. Establish whether it refers to a decision period, a planned technical change, a review deadline or a change in service access. Compare that date with the document version and any later update. If the text describes an alternative route, record its steps, responsible party and stated conditions alongside the principal proposal. Keep the treatment of existing records separate from the availability of future service. These distinctions make a timeline reviewable without turning an announcement into evidence that every described event has occurred.


9. Rights and request procedures

Locate the applicable procedure for each relevant request:


  • Withdrawal: check which permission a described withdrawal addresses, how it is submitted and what the notice says about its effect on earlier or continuing activity.

  • Objection: identify the activity concerned and the procedure stated for raising a question or objection about it.

  • Access: find the participant’s procedure for requesting information about its records.

  • Correction: find how to report inaccurate or incomplete records.

  • Deletion: review the scope, conditions and separate retention rules for the records concerned.

  • Restriction: read when and how a request to limit processing applies.

  • Portability: check the available format, scope and conditions.

  • Complaints: verify the recipient and escalation path for the entity and activity being reviewed. Confirm the channel through official information; a brand alone does not identify an authority.

  • Communication preferences: examine how a change to a marketing preference is described and which sender, purpose and channel it covers. Keep that request separate from questions about identity records, service access or another participant’s processing.


Before sending a request, verify the destination through the responsible participant’s current official documentation.


10. Communication purposes and preferences

A document can discuss service messages and promotional communications together. Identify the sender, purpose and channel for each. Distinguish information about an existing service from an invitation to receive messages about other products or offers.

For separate choices, record what each covers and any stated connection between them. Check the effect of accepting or declining a communication preference independently of the proposed handling of identity records.


Compare a previous preference with the sender and purpose named in the proposal. Similar branding does not establish the same entity, audience or communication scope. Record the applicable wording and version, and leave questions about a prior preference unresolved until the relevant documentation answers them.


Read how a notice describes changing a preference after a decision. Identify the channel, the activity concerned and any stated conditions. Keep the wording reviewed and the action requested separate from a general account-status message, so a communication choice remains distinct from another service instruction.


11. Recording the review and its outcome

Before documenting an outcome, bring the scope back together: the exact participants, the categories of information, the described process, the purpose of each step and the terms referenced by the proposal. Resolve mismatches between the summary and the detailed sections. A familiar technical tool or a recognizable account name should not replace the record of what the documents actually describe.


For any decision mechanism, read the words attached to the action and identify the evidence that would show what was submitted. Keep an indication on a screen separate from a record confirming that a particular instruction was received or completed. Review any described completion conditions in the context of the same proposal and document version.


A useful review record identifies the documents read, the date of review, the questions resolved and the points still requiring clarification. Record any later instruction separately with its stated scope. Reading a notice, saving these notes and authorizing the movement of records are different actions.

Copyright 2026 DTCC Trading. All rights reserved.
Tokenization on Stellar. Multichain interoperability.

Tokenized assets carry risks. Understand the asset, issuer and network before proceeding. Learn more.

Copyright 2026 DTCC Trading. All rights reserved.
Tokenization on Stellar. Multichain interoperability.

Tokenized assets carry risks. Understand the asset, issuer and network before proceeding. Learn more.

Copyright 2026 DTCC Trading. All rights reserved.
Tokenization on Stellar. Multichain interoperability.

Tokenized assets carry risks. Understand the asset, issuer and network before proceeding. Learn more.