# Tax reporting and data residency

> Define tax ownership, account and transaction records, CRS/FATCA classification, withholding, customer statements, retention, residency, transfers, and deletion.

Tax reporting and data location are separate control domains, but both depend on a reliable jurisdiction
map. Record where the customer is resident, which entity provides the account, where the data is stored
and accessed, and which party files each report.

> Obtain a valid self-certification and apply the locally required reasonableness and indicia checks.
> Citizenship, phone country, funding currency, and IP address may be indicators, but none alone proves
> tax residence.

## Responsibility matrix

| Activity                                 | Partner                                      | MyStocks / appointed provider                                     |
| ---------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------- |
| Tax self-certification                   | Collect, validate, refresh, and retain       | Receive only fields required for operations/reporting             |
| Reporting-financial-institution analysis | Confirm own entity status                    | Confirm platform/custody entity status                            |
| Transaction and position records         | Retain customer-facing ledger and statements | Provide orders, executions, dividends, fees, FX, and custody data |
| Withholding                              | Disclose customer treatment and reconcile    | Apply/report where contractually assigned                         |
| CRS/FATCA or local filing                | File where legally assigned                  | Provide agreed data extract and corrections support               |
| Customer tax advice                      | Do not provide unless authorised             | API output is information, not personal tax advice                |

## Minimum tax data set

- Legal name, address, date of birth/incorporation, and account identifier.
- Jurisdiction(s) of tax residence and taxpayer identification number or documented exception.
- Entity classification, controlling persons, and their tax residences where applicable.
- Self-certification version, signature/consent, date received, validation result, and expiry/change status.
- Gross proceeds, dividends, interest/distributions, withholding, fees, currency, and FX metadata.
- Corrections, cancellations, account closure, and report-submission identifiers.

Re-document when circumstances conflict with an existing self-certification. Do not silently overwrite
the original; preserve the effective dates and correction trail.

## Statement and reporting controls

1. Reconcile reportable cash and positions to the same ledger used for customer statements.
2. Use immutable execution and corporate-action records; distinguish trade date from settlement date.
3. Preserve local-market currency, USD ledger effect, FX rate/source, and tax withheld.
4. Validate report schemas, record counts, totals, duplicates, and jurisdiction codes before submission.
5. Track acceptance, rejection, correction, and customer-notification status.

See [Statements and confirms](/partners/docs/statements-confirms), tax lots and gains endpoints, and the
daily [Reconciliation](/partners/docs/daily-reconciliation) workflow.

## Data residency and transfer register

For each data category, record:

| Question                   | Required evidence                                                           |
| -------------------------- | --------------------------------------------------------------------------- |
| What is processed?         | Data inventory and classification                                           |
| Why is it processed?       | Purpose and lawful basis/contractual necessity                              |
| Where is it stored?        | Primary region, replicas, logs, backups, and disaster recovery              |
| Who can access it?         | Entity, role, country, support access, and authentication controls          |
| Who receives it?           | Broker, custodian, KYC vendor, cloud provider, tax authority, regulator     |
| What enables the transfer? | Adequacy, contract, consent, statutory gateway, or other approved mechanism |
| How long is it retained?   | Record-specific schedule and deletion/hold rule                             |

“Hosted in region” is not a complete answer if support, telemetry, backups, or subprocessors can access
the data elsewhere. Evaluate the entire processing chain.

## Production evidence

- Executed DPA and controller/processor responsibility record.
- Current data map, subprocessor register, transfer mechanism, and transfer-risk assessment where required.
- Tax responsibility matrix by entity, product, account type, and jurisdiction.
- Valid self-certification workflow and change-in-circumstances process.
- Sample annual statement/report, reconciliation, submission receipt, and correction test.
- Retention schedule covering financial records, KYC, disputes, legal holds, backups, and sandbox deletion.

## Reference standards

- [OECD consolidated Common Reporting Standard](https://www.oecd.org/content/dam/oecd/en/publications/reports/2025/04/consolidated-text-of-the-common-reporting-standard-2025_e478bc04/055664b1-en.pdf)
- [OECD automatic exchange of financial account information](https://www.oecd.org/en/topics/sub-issues/international-standards-on-tax-transparency/automatic-exchange-of-information.html)

See [Privacy, retention, and residency](/partners/docs/privacy-compliance) for platform retention and
production-certification requirements.