Buying QA services for a fintech product

A fintech company buying testing services has the same goals as any other buyer: a capable team, sound test design, fair terms and a clean exit. What changes is the set of rules that sit around the product. Card data rules shape how test data is built. Regulators expect certain terms in outsourcing and ICT contracts. Auditors expect evidence.

This post covers the points where a fintech QA purchase differs.

Test data under PCI DSS

If your product handles payment card data, PCI DSS applies to your cardholder data environment. Two requirements in PCI DSS v4.0 bear directly on testing:

• Requirement 6.5.5 says live primary account numbers (PANs) are not used in pre-production environments, except where those environments are included in the cardholder data environment and protected under all applicable PCI DSS requirements.
• Requirement 6.5.6 says test data and test accounts are removed from system components before the system goes into production.

For a testing vendor, this means the default is test card numbers and synthetic data. Write that into the RFP and the contract. A vendor that asks for copies of production data to make testing realistic is proposing to bring its environment into PCI DSS scope, or to break the rule.

Third-party service providers under PCI DSS

Requirement 12.8 covers third-party service providers with which account data is shared or that could affect the security of account data. It asks you to keep a list of such providers, to have written agreements in which they acknowledge responsibility for the security of the account data they handle, to follow a due diligence process before engagement, to monitor their compliance status at least once every twelve months, and to record which requirements each provider manages.

The standard also notes that using a compliant provider does not make you compliant or remove your own responsibility. If a testing vendor could affect the security of your cardholder data environment, for example through access to a build pipeline that deploys to it, bring it into this process.

Regulator expectations on outsourcing and ICT contracts

EU. The Digital Operational Resilience Act (DORA) applies to EU financial entities. Article 30 lists key contractual provisions for ICT services, including a description of the services and whether subcontracting is allowed, the locations where services are provided and data processed, service level descriptions, termination rights and minimum notice periods. For services that support critical or important functions, it adds precise quantitative and qualitative performance targets, unrestricted rights of access, inspection and audit, and exit strategies with a mandatory transition period.

The EBA guidelines on outsourcing arrangements set similar expectations for outsourced functions. The EBA has published new guidelines on third-party risk for non-ICT services that will repeal them once applicable, so confirm with your compliance team which rules cover your arrangement.

US. The 2023 interagency guidance on third-party relationships from US banking regulators lists contract factors including performance measures, the right to audit, subcontracting, default and termination, and a clause stating that the third party's performance is subject to regulatory examination. Fintech firms that partner with banks often inherit these expectations through the bank's own third-party programme.

Evidence that survives an audit

In regulated work, testing evidence matters beyond the release. Auditors may ask what was tested before a change went live, who approved the result and whether defects were resolved. Require the vendor to:

• store test plans, results and defect records in systems you own;
• link test results to the release or change they supported;
• keep records for the retention period your policies require;
• hand everything back in a usable format at exit.

Personal data

Most fintech products process personal data as well as card data. Where testers process personal data on your behalf, GDPR Article 28 requires a written contract with the processor covering, among other things, documented instructions, confidentiality, security, subprocessors, and deletion or return of data at the end. Masked or synthetic data reduces the exposure, but logs and screenshots can still contain personal data.

Adjust your scoring

For a fintech purchase, increase the weight of criteria covering data handling, audit rights, security evidence and exit. Treat a refusal to accept audit and information rights as a gating issue if your regulator expects them.

What this means for your selection

Run the due diligence checklist with your compliance team, and use the contract clause builder for audit rights, data processing, subprocessor approval and exit terms. The RFP generator lets you state test data rules up front. For more detail, read test data and GDPR, security testing scope, the vendor security questionnaire guide and exit planning.