> For the complete documentation index, see [llms.txt](https://doc.api.tieto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.api.tieto.com/standards-and-compliance/gdpr.md). # GDPR What personal data the platform holds and deliberately does not hold, how consent is recorded, and how retention, masking and erasure are handled. The platform processes personal data on behalf of regulated institutions, and it is designed to hold as little of it as the job allows. Two features do most of the work: authentication stays with the bank, so credentials never reach the platform; and sensitive fields are masked before storage rather than cleaned afterwards. ## What personal data exists | Category | Contents | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Registered users | Email address, first and last name, and a password held by the identity provider. Nothing else. | | Customer data in API records | Data that necessarily appears in the exchanges the platform audits — account identifiers and currency, account names, customer identifiers, names, IP address, device and location information where the third party supplies it, and creditor details on payment initiations | | Consents | The authorization itself, its terms, its owners and its authentication history | Customer identifiers are the bank's own client references. The platform does not mint identities for banking customers. ## What the platform does not hold **Customers' banking credentials are never stored or managed by the platform.** Strong customer authentication happens against the bank's own authentication server; credentials remain the responsibility of the bank and the third party. This removes the most sensitive category of personal data from the platform's footprint entirely. ## Consent as a first-class object Third-party access to a payment account rests on the customer's consent, and the platform treats that consent as a stored, inspectable object rather than a side effect of an API call — recording what was agreed, by whom, for how long, over which accounts, and who withdrew it. The practical consequence matters for data subject rights. Where the bank integrates the Consent Management service into its own digital channels, the customer can review and withdraw every third-party consent inside internet or mobile banking, rather than having to return to the third party that requested it. A consent withdrawn there is recorded as such and reflected everywhere else. ## Data minimization and masking Sensitive payload fields and headers are masked before records reach the audit store, with control over how much of a value stays visible. Masking happens on the way out, so the unmasked value is never written to storage and later removed. ## Where data is stored | Store | Contents | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Relational database | Operational data — agreements, applications, configuration — plus consents as business data | | Audit store | Full records of API exchanges, written asynchronously through a message queue so that auditing never sits in the critical path of a call | Data at rest sits on encrypted volumes in a fault-tolerant configuration. Records belonging to a single call share a trace identifier, which is what makes a subject access request answerable without reconstructing a call from fragments. ## Retention Retention is configured per record type rather than globally: * Operational and infrastructure logs — short, typically days to weeks. * The transactional audit trail — longer, typically at least a year, because the depth of statistics a regulator can request sets a floor on it. * Older records move to cold storage rather than remaining in the live store. Because the retention period per record type is a deployment decision, it can be aligned to the institution's own data protection policy instead of a vendor default. ## Erasure Deleting a third party, a user or a tenant erases the record from the database and **anonymizes the corresponding audit trail**. This is the design point that lets an erasure request be honored without destroying the audit history that regulation requires the institution to keep — the events remain, the person does not. ## Access control and accountability * Role-based, least-privilege access on every portal, with fixed roles rather than freely composed permissions, which makes an access review tractable. * Mandatory two-factor authentication for every administrative user. * No self-elevation of privilege — granting an administrative role always involves a second person. * Four-eyes approval on consequential change, with the author, reviewer, timestamps and comments retained as a revision record. * Tenant isolation, so a bank on shared infrastructure cannot see another bank's customers, consents or commercial terms. * User management actions written to a dedicated audit index, separate from application logging. ## Residency Where data residency is a requirement rather than a preference, the on-premises model keeps all personal data inside the institution's own estate. In the managed model, hosting locations are set out in the service agreement. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://doc.api.tieto.com/standards-and-compliance/gdpr.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.