Who this manual is for
Individuals, organizations, privacy officers and authorized participating institutions. Readers should first understand the product scope and respect the fact that roles, contracts, source permissions and approvals cannot be created by a mere software screen.
Before starting
- Use only an official, current and authorized release.
- Identify which organization or account is responsible for the action.
- Review the permissions, data classification, allowed scope and supporting rights.
- Verify current product availability and the limits of published evidence.
- Do not disclose passwords, access tokens, financial details, sensitive source records or confidential algorithms.
01 — Review a connection request
Confirm the named source and recipient. Read the purpose, fields, expiry, retention and onward-sharing conditions. Refuse if the scope is unfamiliar or wider than needed.
02 — Approve a limited contribution
Where a verified production service permits it, authenticate through the provider’s official process, select the minimum fields, approve the stated purpose and retain a permission receipt.
03 — Review prior permissions
Use the official permission history when available. Compare recipient, purpose, timestamps, data categories and expiration. Check for any unexpected ongoing connection.
04 — Withdraw future access
Use the withdrawal control or authorized support channel, record acknowledgement, and review whether third-party deletion or retained records remain subject to a separate process.
05 — Question commercial reuse
Ask for the exact asset or result proposed for commercialization, the underlying permission and your rights under the contribution agreement. Do not assume a ticker establishes consent.
06 — Report a privacy concern
Collect the permission reference, affected source and timeframe; avoid transmitting additional sensitive data in the report. Escalate through BTG’s official contact and appropriate privacy authority where relevant.
Understanding statuses and results
Proposed: a design or candidate, not an accepted product or offering. Qualified: supported by named evidence within a stated test scope. Authorized: a competent rights holder, organization or regulator has given the particular approval required. Completed: the independently defined outcome has actually occurred, including any external settlement or delivery where applicable.
Common questions
Does the public document grant access?
No. Publishing a description or a manual does not give readers access to private software, underlying data or investments.
Does a test pass establish production readiness?
No. Tests must be interpreted by version and scope; actual production readiness requires the applicable operational, legal and security qualifications.
Who decides data or investment rights?
The legally competent rights holder, issuer, contracting parties and applicable authorities—not a software identifier or automation alone.
Support and issue records
Record the date, relevant public identifier, product version if known, symptom or question, steps observed and the minimum permitted evidence. Report through BTG’s official contact page. Avoid attaching unrelated confidential or personal records.
Detailed workflow and decision record
This is a task and review manual for a planned or specifically authorized deployment. Screen names, buttons, account permissions and automatic outcomes must be checked against the actual tested product version; where the UI has not been verified, instructions are deliberately expressed as actions, not invented clicks.
Review request
Check the exact source, recipient, fields, purpose, expiration, location and proposed commercial use.
Decide
Approve only the minimum necessary permission or decline without penalty beyond the feature that needs the data.
Inspect activity
Review an intelligible grant and delivery history with dates, scope and recipients.
Withdraw
Find the grant identifier, initiate cancellation, retain confirmation and check effects on future accesses.
Request correction
Identify inaccurate or overbroad records; preserve a case identifier and seek proper remedy from the controller.
Report incident
Supply non-sensitive identifiers and impact description using official contact; do not post private data.
Before operating — acceptance checklist
- Identify the actual operating version and service owner.
- Confirm your role and explicit authority for this data, research or financial action.
- Read the purpose, risks, permitted scope and available evidence before taking action.
- Know which support and incident-reporting channel applies and how to stop safely.
- Make no release, resale, rights-transfer or investment decision on a proposed record alone.
Expected workflow
- Identify a source and person or organization with authority
- Explain recipient, data categories, purpose, territory and retention
- Obtain specific permission; refuse by default outside scope
- Minimize, protect and record any authorized transfer
- Enable a record of what was accessed and the terms
- Process withdrawal, correction and exceptional lawful retention
Problem and recovery guide
| What you notice | What to do |
|---|---|
| Unknown source requested | Do not authorize; validate identity and provider authorization. |
| Permission appears wider than desired | Refuse, narrow scope, or request clarification before proceeding. |
| Access continues after withdrawal | Record evidence and escalate as a security/privacy incident; do not assume the UI state stops external systems. |
| Provider restriction encountered | Stop transfer, assess provider terms, preserve non-sensitive failure evidence. |
What the operator should record
- Date, timezone, role and intended action.
- Public object identifier and version, never a secret or private credential.
- The authority, permission or review reference in appropriately protected storage.
- Expected outcome versus observed result, including negative and failed cases.
- Whether action is proposed, internally qualified, externally authorized or actually completed.
- Escalation destination and final decision, if any.
What this manual does not promise
Not every capability described here is available to a public account or installed in a consumer application. Real operation depends on qualified builds, actual provider permissions, formally delegated roles and sometimes legal authorization. Do not infer an available menu, released feature, verified rights entitlement or active securities market from a conceptual workflow.
Documents to request before relying on a result
- User-facing consent notice, granularity and revocation record
- Source authority and platform terms
- Real connector compatibility test by version
- Data-flow map, minimization, retention and deletion handling
- Independent privacy and security assessment
- Incident-response and affected-user notification procedures