> 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/pci-dss.md). # PCI DSS How card data is protected in transit and at rest, the masking mechanism that keeps sensitive authentication data out of stored records, and what the platform never stores at all. Open banking is account-based, but card data still appears in parts of the picture — card account services, funds confirmation against a card-based instrument, and card scheme integrations where a deployment includes them. Wherever it appears, the payment card industry data security standard applies, and the platform is built so that compliance is a configuration decision rather than a redesign. ## The two requirements that bite | Requirement | Concern | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Requirement 3** | Protect stored account data. Sensitive authentication data must not be retained after authorization; the primary account number must be unreadable wherever it is stored. | | **Requirement 4** | Protect account data with strong cryptography during transmission over open networks. | Most of the risk in a platform like this sits in requirement 3, and specifically in logging — because an API platform that audits every exchange in full will, by default, write card data into its audit store. ## How each data element is handled | Data element | In transit | At rest | In the audit store | | ----------------------- | ---------- | ------------------------ | ------------------ | | Primary account number | TLS | Masked | Masked | | Cardholder name | TLS | No additional protection | Present | | Expiration date | TLS | No additional protection | Present | | Service code | TLS | No additional protection | Present | | Full track data | TLS | Not applicable | **Never stored** | | Card verification value | TLS | Not applicable | **Never stored** | | PIN and PIN block | TLS | Not applicable | **Never stored** | The three elements that make up sensitive authentication data are never written to storage in any form. That is a property of the platform, not something an operator has to configure correctly. ## Data element masking Masking is the mechanism that makes the rest defensible, and it is worth understanding because it is an operator responsibility. The audit policy captures every HTTP exchange, and it masks nominated payload fields and headers **before** the record is published to the message queue that feeds the audit store. The data is never written and later cleaned — it is masked on the way out. What is configurable: * Which payload fields to mask, addressed individually or across arrays. * Which request and response headers to mask. * How many leading and trailing characters remain visible, so a primary account number can be stored in the truncated form that support staff need while the middle digits are unreadable. * A pattern matching only the portion of a value that must be hidden, where a field carries more than one kind of data. **Operator responsibility.** To satisfy requirement 3.3, the masking configuration must be applied to every payload field that can carry sensitive authentication data, on every API that can carry it. The platform provides the mechanism and sensible defaults; confirming the coverage against your own card data flows is part of deployment. ## Protection in transit * TLS 1.2 or higher on every connection, with mutual TLS between the platform and the bank's back-office interfaces. * Message-level integrity through JSON Web Signature, so a payload cannot be altered in flight undetected. * Element-level encryption through JSON Web Encryption for particularly sensitive fields, using RSA-2048 key pairs registered per client application, with keys published as a JSON web key set and key identifiers that allow rotation without a coordinated release. Element-level encryption is the option worth considering where card data must traverse a path the operator does not fully control: the protection travels with the data rather than with the connection. ## Software security The platform is developed against the **PCI Software Security Framework**, which replaced PA-DSS, and against OWASP practices for application security. Access to every administrative surface is role-based and least-privilege, with mandatory two-factor authentication and four-eyes approval on consequential change — controls that also serve the standard's requirements on access to cardholder data. ## Scope in practice Two points that usually come up in a compliance review: 1. **The platform does not store customers' banking credentials.** Authentication happens against the bank; credentials remain the responsibility of the bank and the third party. That removes an entire category of scope from the platform's footprint. 2. **Retention is configurable per record type.** Audit records are held for the period the operator's compliance regime requires and then moved to cold storage, so the window in which any card-adjacent data exists is a deliberate decision rather than an accident of defaults. --- # 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/pci-dss.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.