COMPLIANCEJune 17, 2025·9 min read

Password Security for Fintech: PCI-DSS, Open Banking, and API Keys

Fintech companies handle payment data, banking APIs, and customer credentials. Here is the compliance and security architecture that covers all three.

The fintech credential surface

Fintech companies have a uniquely complex credential landscape. They handle customer financial data under PCI-DSS, often integrate with banks via Open Banking APIs under strict authentication requirements, run internal developer access to production systems with real money, and manage API keys that directly control financial transactions. A credential failure in any of these areas can have immediate, large-scale financial consequences.

PCI-DSS v4.0 requirements for fintech

PCI-DSS v4.0 (effective March 2024) raised the password bar for cardholder data environment (CDE) access:

  • Minimum 12 characters for all accounts with CDE access (up from 8 in v3.2.1)
  • Passwords must include uppercase, lowercase, and either number or special character
  • MFA is now required for all access into the CDE, not just remote access
  • Service accounts and system passwords must be managed with the same rigour as user accounts
  • Shared generic accounts (root, admin) are prohibited — all CDE access must be individual and auditable

PassGeni's PCI-DSS preset automatically enforces Requirement 8.3.6 password complexity. Use it for all CDE-adjacent credential generation.

Open Banking and API authentication

Open Banking frameworks (UK Open Banking, EU PSD2) require strong customer authentication (SCA) — typically multi-factor — for payment initiation and account access. API credentials (client IDs, secrets, certificates) must be managed with rotation policies and stored in secrets management systems.

Common failures in fintech Open Banking implementations:

  • API secrets hardcoded in repositories
  • Shared client credentials across development and production environments
  • No rotation schedule for long-lived API credentials
  • Client secrets stored in plaintext in configuration files

Internal developer access to production

In fintech, production database access means access to real transactions and customer financial data. Controls that should be in place:

  • Privileged access management (PAM) for production database and infrastructure access
  • Just-in-time access provisioning (temporary elevation with full audit trail)
  • MFA for all production access without exception
  • Secrets rotation integrated with CI/CD pipelines via a secrets manager (HashiCorp Vault, AWS Secrets Manager)
  • Service account passwords generated to DoD preset standards (15+ characters) with quarterly rotation

API key lifecycle management

Generate API keys with maximum entropy (PassGeni's API generates 40-character keys with full character sets by default). Store only the hash server-side. Display the key once at generation, never again. Build key rotation UI into your dashboard from day one — retrofitting it is expensive and leads to rotation being skipped. Set expiry dates on all non-human API credentials. Scan your repositories for accidentally committed secrets using tools like TruffleHog or GitHub Secret Scanning.

Key topics
fintech securityPCI-DSSopen bankingAPI key securityfinancial compliance
Was this post useful?
Frequently asked questions

Questions about this topic

Does every fintech need PCI-DSS compliance?

+

What are the password requirements for open banking APIs?

+

How should fintech companies handle internal service credentials?

+
More posts

Related reading