APIs enable firms to offer ‘plug and play’ integration for developers and are well established as the go-to connective tissue for embedded finance and platform business models. Developers are the ones literally building these digital financial ecosystems and are an often overlooked customer.
For all the talk of agility and fast time to market, as API use proliferates so too does complexity, maintenance overhead, and risk exposure. Growing complexity is visible, however, risks are frequently more hidden, and within financial services, the challenges are more acute. Standards such as FAPI (Financial-Grade API security standard) enable risk and inefficiency mitigation, and an opportunity to build a competitive advantage.
What are the examples of Sensitive Financial Data and who is it applicable for?
Sensitive financial data refers to any information that can be used to identify an individual, organisation, or account and is typically governed by stringent data protection and compliance requirements. Examples include:
- Personally Identifiable Information (PII): Such as names, addresses, Social Security numbers, and dates of birth.
- Account Information: Account numbers, bank statements, transaction histories, balances, and payment records.
- Authentication Information: Passwords, PINs, and security questions that authenticate a user’s identity within financial systems.
- Credit and Loan Information: Credit scores, credit history, outstanding debts, and loan details.
- Transaction Data: Real-time transaction details, card information, payment histories, and location data tied to transactions.
Sensitive financial data is critical for financial institutions, fintech providers, credit bureaus, payment processors, and any business handling transactional data in industries like e-commerce, insurance, and real estate. B2B fintech APIs for these types of data enable secure, compliant information sharing between businesses, allowing for integrations that prioritize data security and privacy in line with regulatory standards like GDPR, PCI DSS, and FAPI.
You protect data well at rest, so why not make connections for data in transit?
Financial services firms are pretty adept at managing risk around financial data. Regulations such as Europe’s GDPR, and consent-based open finance, focus minds firmly on data security – which is typically extremely well controlled. When it comes to developers and policing connectivity – things are not always as robust. For example, many banks connect into highly secure open finance ecosystems that come with robust security built in – such as Open Finance and PIX in Brazil or Open Banking in the UK – however, their own APIs remain vulnerable with lower grade security practices.
Cryptography alone isn’t the answer.
To meet security and compliance standards firms increasingly depend on cryptography – using certificates and keys to secure connections, authenticate APIs, and enable end-to-end encryption (E2EE). Despite the risks and several high profile breaches, onboarding developers using API keys and API secrets also remains stubbornly commonplace, and introduces all of the inherent vulnerabilities of ‘username and password’ with every new relationship. To understand more about the risks of common API security models and the critical role of cryptography and trust services click here.
Rethinking Key Management: When is Key Rotation Necessary?
Key rotation is a standard practice within frameworks like PCI DSS, aimed at reducing the impact of key compromise by periodically regenerating keys or certificates. While this is generally considered good practice, its necessity hinges on the exportability of the key.
- When Key Rotation is Required:
If a key is exportable, there is an inherent risk that it could be exfiltrated and compromised. In such cases, regular key rotation mitigates the potential impact of unauthorised use by limiting the time a stolen key is valid. - When Key Rotation May Not Be Recommended:
Conversely, if a key is created as non-exportable, meaning it cannot be extracted from its secure environment (such as a hardware security module or a trusted execution environment), the risk of compromise is significantly reduced. In such scenarios, key rotation might not only be unnecessary but could introduce additional risks or complexity. Over-rotation of secure, non-exportable keys can lead to operational inefficiencies and heightened chances of errors, such as improper implementation or inadvertent downtime.
This distinction is crucial for financial services firms aiming to optimise their API security strategies. Implementing non-exportable keys provides a stronger foundation for cryptographic security while potentially reducing the need for key management overheads associated with frequent rotations.
Inefficient integrations add overhead and introduce risk.
Managing these keys and certificates can be cumbersome – particularly if you need to perform a key rotation to periodically regenerate certificates – as is mandated in the Payment Card Industry Data Security Standard (PCI DSS). Key rotation itself is good practice, however, this just reduces the impact of compromise – it does not remove the risk. Without automation, this perpetual requirement creates a poor experience and itself adds risk – as mismanagement often leads to downtime, errors, and security issues. Developers are customers too and cumbersome experiences make it harder to work with you and impact their brand loyalty. These issues will only compound as embedded finance accelerates and your customers expect you to serve them in the platform of their choice. It is both financial and reputational damage you need to prevent.
Forward-leaning firms defend and differentiate.
Standards such as FAPI from the OpenID Foundation promote practices that will prevent a growing number of attackers from breaching APIs, and outlaw the use of API Keys and API Secrets. FAPI builds from existing OAuth 2.0 and OpenID Connect (OIDC) protocols and defines additional technical requirements specifically for the needs of high assurance data sets – such as financial data or payments – and other industries that require higher API security. To ensure the highest levels of trust and security FAPI mandates the use of asymmetric cryptography for various electronic exchanges between parties to mitigate multiple attack vectors.
Make cybersecurity an anchor for competitive advantage.
Compliance and a necessary upgrade to your API security bring an opportunity to drive home a competitive advantage as you expand your role in digital financial ecosystems and embedded finance. Developer experience – ease of use, onboarding, and ongoing maintenance – is also a differentiating factor, just ask Stripe how much effort they devote to this. As financial firms explore monetization and other distribution channels via APIs – and for some, management of a growing third-party ecosystem of collaborators – simplifying management overheads for you and your developer community, whilst also improving security can only be a positive move. Implementing FAPI-based API security is an ideal point to review your developer-facing capability and look for opportunities to future proof – such as introducing highly efficient developer self-service, that mitigate future cost risks.
You can prepare your business to lead on embedded finance as well as reduce the operational expense of securely managing APIs, and create better API-first developer experiences. Raidiam Connect is FAPI grade and has already enabled the secure onboarding of thousands of developers for financial services firms in Australia, Brazil, the UK, and several other countries. It enables a higher-level control plane covering first and third party and internal API consumers that builds on and integrates with your existing authorisation capabilities. To understand how Raidiam Connect simplifies the complex world of API security, certificate, and key management click here.
Authors:
Jacob Morgan,
Dave Oppenheim
