Data Processing Addendum — full text

Effective 7 August 2026 · Version 2026-08

This is the operative text. The Data Processing Agreement summary and the condensed edition presented for acceptance inside Chartping are summaries of this document. Where any of them differs from this text, this text governs.

Preamble and two contexts

This Data Processing Addendum (the "DPA") forms part of, and is incorporated into, the agreement between the parties for the provision of the Chartpingservice (the "Principal Agreement", being our Terms of Service). Where there is a conflict between this DPA and the Principal Agreement concerning the processing of personal data, this DPA prevails. The Licensing module may not be used without this DPA (Terms of Service §6.2(d)).

Chartping is operated by TrendSoft Ltd, incorporated in England and Wales (Company No. 16144241), registered office Aa House 54, 27 Old Gloucester Street, London, WC1N 3AX, United Kingdom ("TrendSoft", "we", "us").

This Addendum governs two distinct relationships:

• Context (a) — Developer ↔ Trader (Licensing). Where a customer (a "Developer") uses the Licensing module to issue, distribute, revoke and manage licences for its own product to its own end users ("Traders"), the Developer is the controller of the Trader personal data and TrendSoft is the Developer's processor for that data (licensing subject attributes and Developer→Trader transport content). Part I is the UK GDPR Article 28(3) contract for that relationship.
• Context (b) — TrendSoft ↔ sub-processor chain. TrendSoft engages the sub-processors listed in §5.3. For TrendSoft's own controller-side data they are TrendSoft's processors; for Trader data under Context (a) they are sub-processors and §5 applies. Part II governs the chain.

Controllership boundary. TrendSoft is controller of the data it collects on its own account — account and authentication data, billing, and monitoring data where the trader is TrendSoft's direct customer — as described in the Privacy Notice. TrendSoft is processor of Trader personal data processed for a Developer's licensing product; the Developer is controller and owns Trader notices and consents. Transport content is carried without interpreting its intent.

Part I — Developer ↔ Chartping (Article 28)

1. Definitions and roles

1.1 Terms have the meanings given in the UK GDPR and the Data Protection Act 2018 (together, "UK Data Protection Law"). "Sub-processor" means a third party engaged by TrendSoft to process personal data on the Developer's behalf. "UK Addendum", "IDTA" and "SCCs" mean the ICO's international data transfer addendum, the ICO's international data transfer agreement, and the EU Standard Contractual Clauses (2021/914, Module Two) respectively. "KVKK" means Turkish Law No. 6698, relevant where Traders in Türkiye are concerned.

1.2 Roles. For the Trader personal data described in §2: the Developer is controller, TrendSoft is processor, processing only on documented instructions (§3.1). If TrendSoft is required by law to process otherwise, it informs the Developer before processing unless the law prohibits it.

1.3 Developer warranties. The Developer warrants that (a) it has a lawful basis for the processing it instructs; (b) it has given all required notices to, and obtained any required consents from, its Traders — including for activation, licensing, transport content and the transfers in §6; and (c) its instructions comply with UK Data Protection Law.

2. Processing scope

2.1 Subject-matter. The Licensing module: issuance, activation, seat enforcement, revocation and lifecycle management of signed entitlements for the Developer's product, and transport of Developer→Trader log and alert content, on the Developer's instructions.

2.2 Duration. The term of the Principal Agreement plus any lawful-retention period (§9.4).

2.3 Nature and purpose. Collection (at activation or redemption), recording, storage, transmission (entitlement delivery and transport), seat enforcement, revocation, and erasure by hard deletion (§9). Purpose: enabling the Developer to license its product and reach its Traders with its own content.

2.4 Categories of personal data.

• Trader binding and descriptive attributes: Developer-defined key/value pairs, supplied by the Developer and stored verbatim (typically a trading-account login such as mt_login; the platform applies no transformation or hashing to what the Developer sends), plus a free-text external reference and a derived one-way subject fingerprint, and a per-device seat key on activation.
• Minimisation instruction (contractual). The Developer must send pseudonymous or hashed references rather than raw direct identifiers (for example a hashed customer email, never a cleartext email), and must not place special-category or criminal-offence data in subject attributes, external references or transport payloads. Direct identifiers the Developer nevertheless sends are stored as received, at the Developer's responsibility.
• Licence and activation metadata: licence id, pseudonymous subject reference, activation timestamps, last-seen, seat usage, licensing-action records.
• Developer→Trader transport payloads: opaque to TrendSoft, not interpreted. They may incidentally contain personal data placed there by the Developer, who is responsible for it as controller. TrendSoft processes transport content only to deliver it and to enforce the acceptable-use rules in the Terms of Service.
• Special-category and criminal-offence data are excluded. The Developer must not instruct their processing without a separate written agreement.

2.5 Data subjects. The Developer's Traders.

2.6 Obligations and rights of the controller. The obligations and rights of the Developer as controller are set out in this DPA (in particular §§1.3, 3.1, 5.2, 8, 9 and 10) and in the Principal Agreement.

3. Processor obligations

TrendSoft shall:

• 3.1 process only on the Developer's documented instructions (including as to transfers), informing the Developer immediately if an instruction appears to infringe UK Data Protection Law. The complete documented instructions are: this DPA, the Principal Agreement, and the Developer's use of the Licensing module's documented features. Additional or modified instructions bind TrendSoft only when agreed in writing, and TrendSoft may charge reasonable fees for instruction changes requiring material additional work;
• 3.2 ensure persons authorised to process the data are bound by confidentiality — currently the Director, with any future staff bound contractually before access;
• 3.3 implement the security measures in §4;
• 3.4 engage sub-processors only in accordance with §5;
• 3.5 assist the Developer, insofar as possible, with data-subject requests (§8) and with the Developer's Articles 32–36 obligations (security, breach notification, data protection impact assessment, prior consultation), taking into account the information available to TrendSoft;
• 3.6 delete or return the data in accordance with §9;
• 3.7 make available the information necessary to demonstrate Article 28 compliance and allow audits in accordance with §10.

4. Security measures (Article 32)

These are the controls that exist. No certifications are claimed.

4.1 Transport security. TLS for all public traffic, terminating at the Cloudflare edge for the service hostnames. The agent-to-cloud channel additionally uses OAuth tokens bound with DPoP proof-of-possession and anti-replay protection, with short-lived access tokens (15 minutes).

4.2 Access control. OpenID Connect sign-in; passwords of at least 12 characters with breached-password screening; optional TOTP two-factor authentication; per-email sign-in throttling as the brute-force control on the password path (account lockout is deliberately not driven by unauthenticated sign-in failures, so that lockout cannot be used as a denial-of-service). Operator access is allow-listed and two-factor-mandatory, re-checked on every token refresh, and every operator action that changes user data is written to an append-only audit log with before and after values and a required reason. Operator reads are not currently audited.

4.3 Encryption at rest. Broker and exchange API credentials are encrypted at field level with AES-256-GCM under a rotatable key ring, with a re-wrap sweep on rotation and tamper detection that fails closed. Platform storage encryption is host-level disk encryption on the dedicated servers the service runs on. Because those are dedicated servers rather than a managed platform, that encryption is not inherited from a provider: it is ours to configure and evidence, and it forms part of the platform assurance we complete before the service carries production data. There is no per-subject data encryption key and no crypto-shredding — deletion is hard deletion (§9).

4.4 Secrets. Application secrets and signing material are held in Azure Key Vault, with per-service vaults, least-privilege service principals and an explicit secret allow-list. Production start-up fails loudly on missing or development-grade secrets.

4.5 Signing and integrity. Entitlements are signed with Ed25519 under rotatable key ids; inbound provider webhooks are signature-verified; the agent self-update feed is signature-pinned and release builds fail closed on non-production keys.

4.6 Isolation. Per-user application-level data scoping with no cross-tenant access paths; cross-tenant sharing features ship fail-closed behind flags; and tenant-boundary actions are audited.

4.7 Read-only design. No order-placement or withdrawal code path exists in the service. Connected credentials are scope-verified where the platform allows it and rejected if verifiably write-capable.

4.8 Availability. A documented backup and restore drill exists. Automated backups are a provisioning item we complete before launch and are governed by our Backup and Disaster Recovery Policy. Until they are provisioned, our availability commitments are limited accordingly — we state this rather than imply a regime that is not yet running.

5. Sub-processors

5.1 General authorisation is given for the list in §5.3. Each sub-processor is bound by written contract to obligations no less protective than these, and TrendSoft remains fully liable for each sub-processor's performance.

5.2 Changes. We give at least 30 days' prior notice of any addition or replacement, by email to the address on the Developer's account, by a notice in the Service, and in the change history published at chartping.com/legal/subprocessors. The 30 days is enforced by the system that publishes the notice — it refuses a shorter one — rather than left to care, because this period is a term of this contract and not a target. The Developer may object on reasonable data-protection grounds; an unresolved objection gives a right to terminate the affected service under the Principal Agreement. Urgent replacement: where an addition or replacement is urgently necessary to maintain security, legal compliance or service continuity, we may proceed and will notify as soon as reasonably practicable, with the same objection and termination rights applying after the fact.

5.3 Sub-processor list. The public register is chartping.com/legal/subprocessors; it and this table are kept in step.

6. International transfers

6.1 Hosting: the service runs on dedicated servers at Hetzner Online GmbH in Germany, with a standby site in Finland. We are a UK controller, so this is a UK-to-EEA transfer relying on UK adequacy for the EEA; no restricted transfer arises for the hosting leg. Restricted transfers do arise for the United States and global sub-processors listed above, as necessary to provide the service, and the Developer authorises them.

6.2 Safeguards. Each restricted transfer relies on Article 46 safeguards — the EU SCCs (Module Two or Three as applicable) with the UK Addendum, or the UK IDTA — as incorporated in the relevant provider agreement. We verify each instrument before relying on it, and carry out transfer risk assessments.

6.3 No consent-bundling. Service-necessary transfers rest on Article 46 safeguards together with Article 6(1)(b) necessity, never on marketing consent. The Developer remains responsible for its own Trader-facing transfer transparency and, for Traders in Türkiye, for any KVKK Article 9 step its Turkish counsel requires.

7. Personal data breach

7.1 TrendSoft notifies the Developer without undue delay, targeting within 48 hours of becoming aware of a personal data breach affecting Trader personal data, and provides the Article 33(3) information reasonably needed for the Developer's own notification, in phases as it becomes available.

7.2 Notification content follows Article 33(3): nature of the breach, categories and approximate numbers where known, likely consequences, and measures taken.

7.3 Handling follows our Breach Response Procedure: classify, contain using the real levers available (token revocation, secret rotation, feature gates, edge rules), assess risk, notify, record in the breach register, and conduct a post-incident review.

7.4 Where TrendSoft is controller of its own data, TrendSoft notifies the ICO and affected individuals under its own procedure. Under this Part I the Developer makes regulatory notifications and TrendSoft assists.

8. Data-subject requests

8.1 Requests from a Developer's Trader are forwarded to the Developer without undue delay. TrendSoft does not respond substantively — acknowledgement and redirection only.

8.2 On the Developer's documented instruction, TrendSoft assists by retrieving, exporting, correcting or hard-deleting the relevant Trader personal data. This assistance is included in the Developer's subscription at no additional charge.

9. Deletion and return on termination

9.1 On termination or earlier instruction, TrendSoft deletes or returns the Trader personal data at the Developer's choice, subject only to the retention in §9.4.

9.2 Return. Export in a structured, machine-readable format within 30 days of termination.

9.3 Deletion is hard deletion of the underlying records. Trader-local artefacts — the entitlement blob and agent-local files on the Trader's own machine — are outside TrendSoft's control and are removed by uninstall or revocation on the client side.

9.4 Lawful retention. TrendSoft may retain financial and billing records where storage is required by law, and the licensing-action and staff-action audit records needed for accountability and for the establishment, exercise or defence of legal claims, for the periods in our retention schedule — staff-action audit records for six years. For records retained under this clause beyond legally-required storage, TrendSoft acts as an independent controller, processing them solely under Article 6(1)(c) (legal obligation) and Articles 6(1)(f) and 17(3)(e) (defence of legal claims), and for no other purpose.

10. Audit rights

10.1 TrendSoft provides the information necessary to demonstrate Article 28 compliance: this DPA, the technical and organisational measures in Annex 2, the sub-processor and transfer registers, and, as a first line, a completed security questionnaire.

10.2 Audits and inspections are permitted subject to reasonable conditions reflecting that we are a solo operation: (a) audits are remote and document-based first, and are satisfied where possible by our then-current annual security questionnaire or report, which may be shared across customers; (b) inspection beyond that is permitted no more than once per 12 months, save for cause or following a breach, on 30 days' written notice, during business hours, and capped at one business day; (c) scope excludes other customers' and tenants' data, our confidential security-sensitive material, and sub-processor premises — sub-processor assurance is provided through their own audit reports and certifications; (d) auditors must be non-competitors bound by a non-disclosure agreement; and (e) the Developer bears its own costs and reimburses our reasonable time beyond the included questionnaire response at our then-current professional rate, notified in advance of any chargeable work.

11. KVKK (Türkiye) terms

11.1 Where a Developer's Traders are in Türkiye, KVKK obligations attach to the Developer as veri sorumlusu; TrendSoft supports compliance as veri işleyen — the Article 12 security duty is satisfied by §4, and erasure under Article 7 by §9. On cross-border geometry: TrendSoft is a UK company and the platform runs in Germany with a standby site in Finland, so KVKK Article 9 questions concern the Developer's transfer of its Traders' data to TrendSoft and onwards. Mechanism selection and any Kurul notification are for the Developer's and TrendSoft's Turkish counsel.

Part II — Chartping ↔ sub-processors

12.1 For Trader data under Part I, TrendSoft contracts each §5.3 provider on terms no less protective — in practice the provider's standard data processing agreement, verified against our transfer register — and remains liable for their performance.

12.2 For TrendSoft's own controller-side data, the same providers act as TrendSoft's processors under the same agreements. That processing is governed by the Privacy Notice, not by Part I.

12.3 The §6 safeguards apply down the chain, and the evidence for each provider is filed in our transfer register.

13. Precedence, liability, term and governing law

13.1 This DPA prevails over the Principal Agreement for data-processing conflicts. Completed SCC, UK Addendum or IDTA instruments prevail over this DPA where they apply.

13.2 Liability. Liability under this DPA is subject to the Principal Agreement's limitations (Terms of Service §10), save where UK Data Protection Law or the transfer instruments do not permit limitation. Allocation: as between the parties, each bears liability under UK GDPR Article 82 corresponding to its responsibility for the damage, with recourse under Article 82(5). The Developer indemnifies TrendSoft against claims — including data-subject claims and regulatory penalties — to the extent arising from the Developer's breach of §1.3, its unlawful instructions, or content it placed in transport payloads. This indemnity supplements Terms of Service §10.7 and is not subject to the §10.2 liability cap.

13.3 Term. Effective with the Principal Agreement; survives while TrendSoft processes Trader personal data, plus the retention in §9.4.

13.4 Governing law. Governed by the laws of England and Wales, with the exclusive jurisdiction of its courts, save as a transfer instrument requires otherwise.

Annex 1 — Description of processing

Annex 2 — Technical and organisational measures

TLS in transit and a DPoP-bound agent channel (§4.1); OpenID Connect with a 12-character minimum password, breached-password screening, optional TOTP, lockout and throttling, and allow-listed two-factor-mandatory audited operator access (§4.2); AES-256-GCM field encryption of broker credentials with key rotation, plus host-level storage encryption on the dedicated servers (§4.3); Azure Key Vault secrets with an allow-list and fail-loud start-up guards (§4.4); Ed25519 entitlement signing, webhook signature verification and a signed self-update feed (§4.5); per-user scoping, fail-closed cross-tenant gates and append-only audits (§4.6); read-only design with no order or withdrawal path (§4.7); and a documented backup and restore drill, with automated backups completed before launch (§4.8). No certifications are claimed.

Annex 3 — Sub-processor list

As set out in §5.3. The public register is chartping.com/legal/subprocessors.

Questions about this addendum: [email protected].