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.
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:
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.
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.
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.
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.
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.
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.
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.
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