Aeion Auth for Fintech
Identity for financial services. PCI DSS Section 8 unique-ID + MFA + audit log requirements. SOX-aligned access controls for systems touching financial reporting. PSD2 Strong Customer Authentication for EU payment flows. Architecture maps cleanly to all three.
What Fintech Authentication Actually Requires
Three regimes typically apply simultaneously:
PCI DSS Section 8 Mapping
| PCI DSS v4.0 requirement | Aeion Auth evidence |
PSD2 Strong Customer Authentication
SCA requires two of three factors, and dynamic linking to transaction details (the user knows the amount + payee at the authentication moment).
SOX Segregation of Duties
SOX requires that the person who enters financial transactions cannot also approve them, and that the approvers' identities are recorded for the audit trail.
Vendor / API Access (PCI 8.5)
PCI's Section 8.5 + general vendor access rules require that third-party / API consumers be uniquely identifiable, scope-limited, and IP-restricted.
Fintech-Specific FAQ
Aeion is a software platform — software itself isn't PCI-certified, deployments and organizations are. Your AOC (Attestation of Compliance) is between you, your QSA, and your CDE. Aeion provides the identity-layer architecture that satisfies Section 8 + Section 10 controls; you provide the operational compliance.
Aeion's identity layer does NOT touch cardholder data. The Commerce module's payment integrations use third-party processors (Stripe, Adyen, etc.) which keep CHD outside your environment via tokenization. Aeion's role is identity for the operator UI + customer accounts, not card storage.
There's no dedicated one-click access-review UI today. The underlying data is there — query the audit log / login history for every account holding `bookkeeper` / `controller` / `cfo` roles, with last-login and last-failed-login timestamps, and export it — but assembling that into a signed-off review workflow is something your team builds on top of the audit log, not a shipped feature.
Aeion's MFA (TOTP + WebAuthn) and audit log give you the primitives, but PSD2 RTS Article 5's dynamic linking — cryptographically binding a specific transaction's amount/currency/payee into the authentication challenge itself — isn't a feature Aeion ships out of the box. You'd build that binding into your payment flow, using Aeion's MFA challenge + audit log as the underlying mechanism.
DORA's auth-relevant requirements (multi-factor for privileged access, audit logging, third-party risk management) map to the same Section 8 architecture. Aegis's backup posture (pgBackRest with off-site immutable storage via S3 Object Lock) addresses the resilience-of-evidence requirement.
Yes — every API key supports a hard expiry date. Aeion rejects expired keys at the verification step. Batch key-rotation tooling in the admin panel is included on every deployment.