Document type: reference guide
Scope: cookies and browser storage
1. About this guide
DTCC Trading has not published an operative cookie policy or verified technology inventory here. This guide explains how to read storage information, purposes and controls; it does not describe a confirmed deployment or record your consent.
Read the related privacy information for the wider document context. A cookie inventory describes technologies; a privacy notice explains the responsible parties and handling of personal information. Compare their scope and versions before treating either document as an account of a particular service.
2. Cookies and related technologies
A cookie is a small piece of data that a browser stores for a site and can send with later requests. Its meaning depends on the value and the application using it. Reading the name alone does not establish its purpose, sensitivity or lifetime.
2.1 Distinguish the mechanisms:
a. Local storage: Review the values saved by a site and the code that reads, changes or removes them.
b. Measurement pixels: Identify the request triggered by loading a resource and the information sent with that request.
c. Browser identifiers: Establish what an identifier connects and whether it can be combined with other records.
d. Interaction records and fingerprinting: Separate recordings of page activity from identifiers inferred from device characteristics. An inventory should explain which mechanism is involved and what it reveals.
3. Reading purpose categories
3.1 Functions described as necessary
3.1.1 A necessary-function category should identify the specific feature served by each item. A broad label such as security or convenience is not a substitute for explaining the action, data and dependency. Useful distinctions include:
a. Session continuity: identify the record that connects successive steps, when that association ends and how the feature behaves without it. A session token is different from a complete activity history.
b. Transaction protection: separate information used to authenticate an instruction from information used to assess abuse. Establish which provider receives each field, the scope of its use and how the purpose relates to the requested transaction.
c. Support continuity: distinguish an interface state from the content of a conversation. A document should explain whether the value identifies a browser, reconnects a conversation or stores a display choice.
d. Choice records: describe how a preference is represented, which version of a notice it refers to and how the setting is applied. The presence of a saved choice alone does not explain every processing activity.
e. Challenge outcomes: examine whether a value records a completed security check, identifies repeated attempts or links activity across requests. The inventory should explain its scope without suggesting that a single cookie guarantees availability or prevents every attack.
3.1.2 Purpose and legal justification are separate parts of a notice. First identify the requested function and the storage it actually needs; then read the responsible entity’s explanation of the applicable requirements. A technology name or category cannot establish the legal basis of its use. Keep unverified classifications open for review.
3.1.3 A retention description should distinguish the lifetime of a browser value from the lifetime of a related server record. Record the event that starts the period, whether activity renews it and what removal changes. A phrase such as session only needs an explanation of how that session is defined. A renewed value can therefore have a different expiry from the original one.
3.2 Measurement and performance
Measurement information can describe visits, feature use, response times or failures. A useful notice separates the question being measured from the records collected to answer it. Review whether events are associated with an identifier, combined across visits or linked with information from elsewhere. Also distinguish a report that contains totals from the underlying event records used to produce it. A summary chart does not by itself establish that the source data is anonymous or that every identifier has been removed.
3.2.1 Visit and event measurement. Start with the event definition, such as a page view or a completed interaction. Establish which fields accompany it and whether repeat events can be connected through a visit identifier or a browser identifier. Check the distinction between raw observations and aggregated reports, the time window used for analysis and the recipients of each record. The inventory should identify the implemented configuration; a product’s general documentation does not prove which options a site has enabled.
3.2.2 Search and referral analysis. A discovery report may answer how a visitor reached a page or which outside reference led to a visit. Review the difference between public search information, referring-page details and events recorded inside the site. These inputs have different sources and scopes. A useful description explains which fields are collected directly, which are supplied by another party and which are inferred. It should also distinguish measuring a page’s visibility from identifying the person who viewed it.
3.2.3 Interface measurement. Page-level measurements and component-level events answer different questions. A click count does not explain why a person clicked, and elapsed time does not necessarily measure active attention. Review event names, triggers and the interpretation applied to them. If a measurement is stored locally before it is sent, the documentation should explain that intermediate record and the conditions for transmission.
Documenting the purpose. A measurement plan should connect each collected field to a defined question. Read the applicable notice for the responsible entity’s explanation of choices and legal grounds. Technical usefulness does not settle those questions, and a statement about one measurement category should not be extended automatically to another.
3.2.4 Business-visit analysis. An inferred organisation label is different from a verified identity. When a service associates a visit with company information, examine the source of the association, its uncertainty and whether individual activity is linked to it. A useful notice distinguishes an observed request from an inference drawn from that request. It should also explain whether an identifier is retained across visits, how it is matched and which retention rule applies to the underlying record rather than merely to a report. Keep that inference separate from an account detail supplied directly by a visitor.
3.3 Preferences and interface choices
Preference information describes choices such as language, display units or presentation settings. Review what is saved, whether the choice applies to one device or an account and which features read it. A setting used for presentation should be distinguished from evidence about a person’s location, eligibility or identity.
Two separate questions:
a. Display settings: A chosen region or currency can affect formatting without proving a visitor’s residence or establishing that a service is available there. The notice should explain how the setting is used and whether it can be changed.
b. Communication settings: A preferred language, an open panel and a conversation history are different kinds of information. Review the purpose and storage location of each instead of treating them as one undifferentiated support preference.
3.3.1 Remembering a choice. Check whether a preference survives a reload, a new session or a visit from another device. Those are separate behaviours.
3.3.2 Explaining the choice. The interface should describe what a setting controls. Read the associated notice to determine its scope rather than assuming that a convenient default represents an informed preference.
3.4 Values stored in the browser
Web storage keeps values associated with a site in the browser. Local storage and session storage have different lifetimes, and neither should be confused with a remote account record. Review the key, the information represented by its value and the feature that reads it. A locally stored value can still be read by site code, so its location alone does not establish its confidentiality.
Examples of records to distinguish:
a. Cached prices: A saved observation needs a source and timestamp. A platform overview cannot establish that an older value is a current executable quote.
b. Cached statistics: Review the period, units and update conditions behind a stored total. Reusing a value may improve loading while leaving its original observation time unchanged.
c. Interface state: A dismissed prompt, chosen language and completed panel step describe different events. A saved flag should not be treated as proof of identity, legal eligibility or completion of an external transaction.
3.4.1 Storage lifetime. Read whether a value is tied to a tab, remains across visits or is removed by application logic or browser controls.
3.4.2 Storage scope. Review the site origin, the fields stored and the code allowed to use them. Performance or convenience explains a design purpose; it does not by itself answer privacy or legal questions.
3.5 Advertising and audience information
Advertising information can connect an impression, a visit and a later event. Before interpreting a campaign report, identify which of those events was observed and which relationship was inferred. Review the parties receiving identifiers and whether activity from different contexts is combined. A marketing label alone does not describe that data flow.
3.5.1 Attribution and audience records
A technology inventory should distinguish attribution identifiers, choice records and audience identifiers. Each has a different purpose. Read which event creates the value, which parties can read it and whether it links a visit with an account or activity elsewhere. An audience category is an interpretation of recorded information, not proof of a person’s interests.
Questions for a campaign description:
Which recorded event is counted as a conversion?
Which observations support an audience classification?
Which identifiers connect an earlier visit to a later message?
A record can contain time, page and device information without containing a person’s name. Review whether those fields become identifying when combined with other records. Replacing a direct identifier with a code does not, by itself, explain who can reconnect the code with additional information.
3.5.2 A change in advertising technology should prompt a review of the following information:
a. The purpose: identify the new measurement or audience question and why a new technology is involved.
b. The data flow: list the fields, recipients and connections to other information. Distinguish a new provider from a new use of an existing provider.
c. The controls: explain which choices affect the activity and whether previous settings carry over to the revised configuration.
d. The document record: identify the version, review date and applicable service or jurisdiction. A change log should make the difference understandable without implying that an earlier choice covers a newly introduced purpose.
An example in this guide does not establish that an advertising technology is present on DTCC Trading.
4. Lifetime, origin and scope
Duration and origin answer different questions. Review how long a value remains and which site or provider controls its use.
4.1 Session scope. A browser defines the boundary of a session. Closing a window is not a reliable description for every configuration because some browsers restore sessions. Read the actual behaviour before interpreting a lifetime label.
4.2 Persistent scope. A value with an explicit expiry can remain across visits until it expires or is removed. Review whether a new event resets the expiry and distinguish that browser lifetime from any related records kept by a service.
4.3 Site context. Identify the site being visited and the domain associated with a cookie. A familiar brand name does not establish who controls a particular domain or which organisation receives the associated information.
4.4 External technology context. A page can include resources supplied from elsewhere. Review the requests those resources make, the domains involved and the information returned or stored. A site notice and a provider notice may describe different parts of that process; their roles and scopes need to be read together.
4.5 Purpose and authority. Keep technical origin, business purpose and the responsible entity’s legal explanation separate. One field cannot substitute for the others.
5. Reading the legal context
The applicable legal context depends on the activity and jurisdiction. Use current official guidance for that specific context.
5.1 European Union: questions to resolve
Choice and information: Identify the purpose presented to the user, the action recording a choice and the corresponding version of the notice.
Necessity and purpose: Review the function described and the evidence connecting the stored information to that particular function.
Service relationship: Identify the requested service and responsible entity before interpreting any statement about a contractual role.
5.2 United Kingdom: document scope.
Read current guidance from the relevant authority for both storage technologies and personal-information processing. A description of one activity should not be treated as a complete explanation of every requirement applying to a service.
5.3 United States: applicable scope
Establish which state, service and type of information a notice addresses.
Read the meaning of any described sale, sharing or targeted-advertising activity in the applicable official guidance; everyday wording may not capture the relevant scope.
Review request procedures and stated exceptions separately. A category label does not establish how a particular request will be handled.
5.4 Other jurisdictions.
Find the current responsible authority and read its guidance in context. Do not assume that a notice prepared for one jurisdiction answers every question in another.
6. Understanding available controls
A control needs a clear scope: what it changes, where it applies and what remains outside it.
6.1 Preference interfaces
6.1.1 Finding the control. Identify the actual settings entry point and the notice associated with it. A reference to a preference centre in a document is not evidence that a working control exists on a particular page.
6.1.2 Categories and effects. Read what each switch enables or prevents, including the associated purposes and providers. Distinguish a category-wide choice from a setting affecting one feature. If a control is unavailable, the interface needs enough context to explain what the user can still review.
6.1.3 Level of detail. Check whether choices apply by purpose, provider or technology. An inventory and the settings interface should use labels that can be matched without guesswork.
6.1.4 Changing a choice. A useful explanation distinguishes a future setting change from the treatment of information already collected. Read the documented effect and timing rather than assuming that one switch removes all earlier records.
6.1.5 Remembering settings. Review where a choice is stored and whether it applies to a browser, device or account. Clearing a browser value may remove the saved setting without changing a separate server record.
6.2 Browser-level settings
6.2.1 Scope of browser controls. Browser settings can affect stored data and future storage. Review the available options and their limits, including:
Whether a setting blocks future cookie storage.
Whether a restriction applies to external site contexts.
Which existing site data a deletion action removes.
Whether an exception applies to one named website.
Whether a prompt informs, blocks or merely records an event.
6.2.2 Effects on a feature. Removing or restricting stored data can change sign-in, preferences or other stateful behaviour. Review the effect on the specific feature instead of assuming that every control has the same result.
6.2.3 Current browser guidance. Use the browser publisher’s instructions for the installed version and device. Menu labels and the scope of deletion options can differ; read the confirmation text before clearing stored data.
6.2.4 Browser privacy signals. A signal sent by a browser and a visible setting inside a website are different mechanisms. Review what the browser sends and what the service documents about receiving it. The presence of a browser option alone does not prove the behaviour of every site visited.
6.3 Provider-specific controls
Google Analytics reference: Provider documentation. For the scope and supported environments of Google’s browser add-on, read the official opt-out add-on page. This reference does not establish use of that service here.
Measurement-provider settings: A provider’s control may apply to a particular browser, account or processing purpose. Read its stated scope alongside the site’s inventory. Blocking a script, removing local data and submitting a request to a provider are different actions.
Communication-provider settings: Review whether a control closes an interface, removes its local state or changes the handling of conversation records.
6.4 Mobile settings. Operating-system permissions, app settings and browser controls can affect different information. Check which application and context each setting covers.
6.5 Request procedures: For questions about a privacy choice or request, use the current applicable notice and an independently verified contact channel.
7. Cross-border information flows
A provider’s headquarters, hosting location and support access location are separate facts. A transfer description should identify the actual recipient, the information involved and the relevant locations. Read that description for the specific service configuration rather than inferring it from a company’s name. This guide establishes no DTCC data-transfer arrangement.
7.1 Measurement recipients
For a measurement service, distinguish the party collecting an event from the parties storing, analysing or accessing it. Review whether the same information is used for the site’s report and for another purpose. A product-level statement about locations or safeguards needs to be connected to the exact service and configuration being described.
7.2 Hosting and operational access
Where a record is hosted does not necessarily identify every place from which it can be accessed. Review the roles of operational teams and additional providers. A useful transfer description makes those distinctions visible instead of listing only one country for the entire process.
7.3 Support and transaction-related recipients
A conversation record, a payment-protection event and a browser identifier can follow different routes. Identify the recipient and purpose for each. Avoid treating all external integrations as one transfer arrangement merely because they appear within the same page or transaction flow.
7.4 Evidence for safeguards
A safeguard claim needs a current source, an identified service and a defined scope. Review the following evidence separately:
7.4.1 Contractual records.
Identify the parties, document version and processing activity covered by a contractual arrangement. A general reference to standard terms does not show which terms govern a particular transfer.
7.4.2 Official status records.
Check current official records for the exact organisation, activity and framework cited. A previous listing or similar legal name is not sufficient evidence for an unrelated recipient or a different service.
7.4.3 Technical measures.
Read which information is protected during transmission, storage and access. An encryption statement needs a defined scope; it should not be interpreted as a promise that every recipient or application is secure.
7.4.4 Organisational measures.
Review who can access the information, the roles they perform and the records supporting access decisions. A policy description and evidence that a control operates are different kinds of information.
7.4.5 Relevant fields.
Compare the fields sent with the stated purpose. A description such as limited data is meaningful only when the actual categories and recipients are identified.
7.4.6 Keeping evidence current.
Note the date of each source and any conditions attached to it. A change of provider, service configuration or processing purpose can require a fresh review of the information supporting a claim.
8. Reading a storage inventory
8.1 Fields and distinctions to check
8.1.1 Session and functional records
Session identifier — Record what the identifier connects and which event ends or renews that association.
Domain and path — Identify the scope in which a cookie can be sent, alongside the feature it serves.
Expiry information — Separate an explicit lifetime from a session-dependent value.
Interface continuity — Distinguish a saved panel state from a complete conversation record.
Recognition across visits — Explain whether the same identifier links separate visits and why that link is needed.
Challenge result — Describe the event recorded, the conditions for reuse and the distinction between a completed check and a guarantee of future security.
Preference version — Connect a stored choice with the notice version and category definitions presented when it was made.
8.1.2 Measurement records
Event definition — State what action creates a recorded event.
Visit grouping — Explain how separate events are associated with one visit.
Time window — Identify the observation period behind a measurement or report.
Request limits — Distinguish control of collection frequency from deletion of existing records.
Provider identity — Identify the organisation receiving events and the service description that explains its role.
Collection trigger — State the action or setting that permits a measurement request to begin.
Storage location — Distinguish values kept in the browser from event records sent to a remote service; each needs its own purpose and lifetime description.
Inferred business label — Identify the source and uncertainty of any organisation associated with a visit.
8.1.3 Presentation preferences
Region and units — Explain whether a choice affects display formatting, a selected market view or some other function.
Language — Identify the interface using the preference and whether the choice applies beyond that interface.
8.1.4 Cached and local values
Cached observation — Record its original timestamp and source, alongside the conditions that cause a newer value to replace it.
Cached total — State the units and period represented; reloading a display is different from observing a new value.
Interface flag — Explain the event represented by the flag and the feature that reads it. A stored value alone does not verify an external action or a person’s eligibility.
8.1.5 Advertising records
Attribution reference — Identify the event relationship being measured and the observation window used to connect it.
Choice reference — Record the purpose and notice version associated with a saved advertising preference.
Audience reference — Explain the information used to form a group and the parties able to use that classification.
8.2 Expiry, removal and replacement
8.2.1 Lifetime boundaries. Read the actual expiry rule and whether a new event renews it. Browser session restoration can affect session values, so a statement about closing a window needs to be checked against the relevant configuration.
8.2.2 Removing local data. Review which categories a browser deletion action includes. Removing cookies, clearing other site storage and requesting deletion of remote records are distinct operations with potentially different results.
8.2.3 Replacing a value. A newly written value can replace an older value in the browser. Review whether historical copies or associated records exist elsewhere before treating replacement as complete deletion.
8.3 Requests about stored information
8.3.1 Identifying the record. Describe the site, approximate period and type of information involved. This helps distinguish a browser-storage question from a request concerning a remote record.
8.3.2 Establishing the scope. Read the applicable notice for the responsible entity, request channel and any stated conditions. Do not infer a process or deadline from an unrelated service’s policy.
8.3.3 Describing the desired change. Specify whether the concern is future collection, a saved preference or previously recorded information. These are different requests.
8.4 Reviewing inventory changes
Compare an inventory with the current configuration and record the observation date. A changed key, provider, purpose or lifetime should remain traceable to its source.
9. Age and audience considerations
9.1 Intended audience. A service description should identify who it is intended for and where any eligibility requirements are stated. This guide does not set a DTCC minimum age or establish an account-registration rule.
9.2 Information involving younger users. Review the responsible service’s explanation of its audience, the information involved and the procedure for raising a concern. A general statement about children’s privacy should be read alongside the actual service scope and current official guidance.
9.3 Age-related interface state. A saved response to a prompt is a record of that response. It should be distinguished from verified identity or eligibility evidence. Read the feature description to establish what the recorded value does and what it does not demonstrate.
10. Security information
A security description should explain which records and stages a measure covers. For cookies, distinguish transmission restrictions, access from page scripts and behaviour in cross-site contexts. For information held elsewhere, review access control, storage protection and the handling of incidents separately. Familiar attribute names or a secure-looking interface are not proof of a complete security programme. Evidence should identify the configuration tested, the scope of the assessment and the date of observation. A technical report, a provider statement and an internal policy answer different questions and should not be treated as interchangeable. This reference makes no certification or guarantee about a DTCC deployment.
When reviewing access arrangements, identify the roles that can read information and the purpose of that access. A statement about authorised staff needs a defined scope and supporting controls.
11. Reading privacy-rights information
The relevant rights and procedures depend on the applicable context. Begin with the responsible entity and current official guidance.
For a context involving the European Union or United Kingdom, read the relevant authority’s guidance and the applicable service notice together. Identify the information and processing activity at issue before interpreting a request procedure. This guide does not set a response deadline or determine the outcome of an individual request.
For a context involving the United States, establish which jurisdiction and service are relevant before relying on a summary of rights. Read how the applicable notice defines the information, recipients and activities involved. Different terms can have specific meanings in official guidance that differ from their everyday use.
For a context involving other jurisdictions, use the relevant authority’s current guidance and the particular service notice. A policy title does not establish its geographical scope.
Before sending a request, verify the responsible entity and the purpose of its channel. Review contact availability and the separate privacy-contact status: privacy-contact availability
If a concern remains unresolved, identify the relevant official authority and read its published procedure. Keep the original notice and correspondence for context.
12. Versions and document changes
A useful document history distinguishes a drafting date, a publication date and any date on which operative terms take effect. Changes should be understandable through their subject: a new technology, a revised purpose, a different recipient or an updated control. Compare the relevant sections and note which service configuration each version describes. A date alone does not show that a notice matches the current implementation. Keep earlier references identifiable so that a statement can be evaluated in the context in which it appeared.
When returning to a notice, check its version and scope before relying on a statement remembered from an earlier visit.
13. Finding an official authority
Identify the jurisdiction and issue before selecting an authority. A reference below does not appoint a DTCC supervisory body.
For a Danish data-protection question, identify the relevant official guidance from Datatilsynet. Verify the authority’s current website and procedure.
Postal details: use the agency’s current official listing.
Telephone details: verify the number at its source.
Email reference: Datatilsynet email
For a UK information-rights question, read the official guidance of the Information Commissioner’s Office. Check its current procedure for the specific concern.
Postal and telephone details can change; use the current official source.
Confirm the issue and jurisdiction before making contact.
Official website: ICO guidance
For an Australian privacy question, review the scope described by the Office of the Australian Information Commissioner and verify its current contact procedure.
Contact details: consult the current OAIC website.
Request route: choose the procedure matching the concern.
Website: https://www.oaic.gov.au
For a United States consumer-protection question, review the role and published guidance of the Federal Trade Commission before choosing a reporting channel.
Jurisdiction and subject: confirm that the issue falls within the agency’s scope.
Contact route: use its current published procedure.
Official website: FTC information
A state authority may address a different scope from a federal agency. Check the relevant official guidance for the particular issue and location.
For another jurisdiction, first identify the current responsible authority and the subject it handles. An agency name in a general reference does not establish its competence over every service or complaint.
14. Contact-document information
A contact notice should distinguish general questions, privacy requests and formal notices, and identify the responsible entity for each.
DTCC Trading contact reference
Responsible legal entity: requires a verified service notice.
Registered or postal address: requires an official source.
General channel: contact availability
Privacy channel: privacy-contact availability
Read any published process and deadline in its own scope. No response commitment or verified DTCC contact channel is created by this guide.
15. Terms used in this guide
Cookie
A small browser record associated with a site that can accompany later requests. Its purpose comes from the application using it. A name alone does not establish its function or duration.
Web storage
Values stored by a site through browser storage APIs. Local and session storage differ in lifetime and should be reviewed separately.
Session scope
A lifetime tied to the browser’s definition of a session, which can be affected by session-restoration behaviour.
Explicit expiry
A defined time or duration associated with a value. Review whether subsequent activity changes that boundary.
Site context
The relationship between the site being visited and the domain associated with a stored value or request.
External recipient
A party outside the immediate page context that receives information. Identify its role and the records it receives.
Identifiable information
Information that relates to a person directly or through its connection with other records; the context of use matters.
Recorded choice
Evidence of a user action linked to a stated purpose and notice version. Read the scope of the choice and how it can be changed.
Coded identifier
A value used instead of a direct name. Review who can connect it with additional information and for which purpose.
Responsible entity
The organisation identified by the applicable notice as responsible for a defined activity. A website brand is not a complete legal identity.
Service recipient
A party receiving information for a stated service purpose. The relationship and scope need to be established from the applicable documents.