Questions Security Leads Ask API Suppliers Before an Open Banking Launch

Why open banking mobile security assurance decides supplier deals

Open banking mobile security assurance decides deals because the security questionnaire, not the demo, is usually the hardest part of winning the contract. It is the evidence pack that answers a regulated buyer’s security questions before they become blockers, and suppliers who arrive with it close faster.

If you build mobile apps, SDKs or API services that touch Open Banking, the bank or TPP you are selling to is a regulated participant whose security lead must satisfy risk, compliance and often an external auditor that your component will not weaken their payment journey.

The participant carries the regulatory exposure, so its security lead will push risk back onto you contractually: warranties about secure development, obligations to test, and rights to see the results. Knowing what they will ask lets you prepare once and reuse the same pack across every prospect.

The contractual and regulatory driver behind the questions

The Open Banking security profile, maintained by Open Banking Limited, is built on the Financial-grade API (FAPI) standard and is mandatory for participants operating under the applicable Open Banking arrangements. It governs how ASPSPs, TPPs and the mobile apps that consume Open Banking APIs handle authorisation, token issuance, certificate-bound access and redirect flows.

Here is the honest position on penetration testing. The security profile does not contain a clause that says “commission a penetration test”. What it mandates is conformance: participants must implement the profile correctly, and conformance certification checks the protocol behaviour. Independent penetration testing sits alongside that as a strong conditional expectation. Regulated participants operate under FCA supervision and the Payment Services Regulations 2017, which require them to manage operational and security risk, and their practical answer to that duty is independent testing evidence from their suppliers. So the mandate on you as a supplier is contractual rather than statutory: it arrives through the due diligence questionnaire and the master services agreement, and it is no less real for that.

The buyer’s obligations flow downstream to every supplier in the chain; our overview of cyber security for financial services covers how UK institutions structure that pressure.

The questions security leads actually ask, and what they are testing for

The same questions recur across pre-launch reviews. Each maps to a control the security lead needs evidenced, not asserted.

“Show us your FAPI conformance and how you deviate from it”

They want proof your authorisation flows follow the security profile: PKCE on the mobile app, certificate-bound tokens where required, no tokens or client secrets embedded in the app binary, and correct validation of redirect URIs. Deviations are where breaches live; a supplier who can name and justify theirs reads as more credible than one who claims none.

“How does the mobile app protect credentials and tokens on the device?”

Expect questions on keychain and keystore usage, certificate pinning, jailbreak and root detection, screen capture protections and what survives in device backups. If you ship an SDK, the question sharpens: your code runs inside someone else’s app, so mishandled storage becomes their breach with your name on the incident report.

“When were the app and APIs last independently tested, and by whom?”

This is the question that stalls procurements. An internal scan or a developer-run tool report rarely convinces a financial services security lead. They want a report they can read under NDA and a retest confirming fixes; a recent report from a CREST-accredited firm usually closes the question in one round.

“What third-party code is inside the app, and who tests it?”

Expect provenance questions: what libraries handle cryptography, what analytics SDKs see, and whether any third-party component can observe consent journeys or account data. Have a software bill of materials ready and know which components fall inside your test scope.

How a pre-launch engagement runs

Pre-launch assessments run in four stages: scoping the consent and payment journeys end to end, testing the mobile builds and APIs, reporting findings graded by exploitability and business impact, and a retest that verifies fixes and produces a clean summary you can share under NDA in due diligence.

Scoping maps the journeys from the mobile app through your APIs to the bank-facing integration, and we walk the actual OAuth and consent flows with your team before quoting, because the number of distinct journeys, not endpoints, drives effort. Mobile application penetration testing against the iOS and Android builds covers on-device storage, transport security, pinning and tamper resistance, while API penetration testing exercises authorisation logic, token handling, object-level access control and the FAPI-specific flows. Reports are written for both your engineers and your customer’s security lead.

Book testing at least six weeks before your launch or procurement deadline so there is room to remediate and retest. For a fuller preparation list, our penetration testing checklist covers what to have ready.

What it costs and how scope drives the price

UK penetration testing is priced by effort at a day rate, typically £1,100 to £1,400 per day. Scope drives the day count: the number of consent and payment journeys, one mobile platform or both, and whether the supporting cloud estate is included.

Engagement	Typical effort	Typical UK range
API penetration test (FAPI-aligned)	4 to 6 days	£4,400 to £8,400
Mobile app test (iOS and Android)	5 to 8 days	£5,500 to £11,200
Combined mobile and API test	8 to 12 days	£8,800 to £16,800
External infrastructure supporting the service	2 to 4 days	£2,200 to £5,600

These are typical UK ranges rather than fixed prices; the exact figure depends on your journeys and estate, and a short scoping call produces a firm quote. For the wider pricing picture across engagement types, see our guide to penetration testing cost in the UK.

How EJN Labs approaches Open Banking supplier assurance

EJN Labs is a UK-based, CREST-accredited penetration testing firm, certified to ISO 27001, ISO 9001 and Cyber Essentials Plus. All testing is delivered by UK-based testers, which matters when due diligence asks where data will be handled during the engagement.

For Open Banking suppliers we test the way your customer’s security lead will evaluate you: the mobile app and the APIs as one connected journey, not two disconnected reports. We chain findings across the boundary, for example weak mobile storage chained with a permissive API authorisation check, because that is how a real attacker works. Reports are written to be shared: an executive summary your prospect’s security lead can read in ten minutes, technical detail your engineers can fix from, and a retest letter that closes the questionnaire. We also scope engagements so the same report serves multiple due diligence processes within its validity window.

Frequently Asked Questions

Does the Open Banking security profile require a penetration test?

No, not by name. The profile, maintained by Open Banking Limited, mandates FAPI-conformant implementation, and conformance certification checks protocol behaviour. Penetration testing is instead a strong conditional expectation, because regulated participants must manage security risk in their own payment services.

The FAPI mandate applies to participants, and their due diligence and contracts almost always require suppliers to evidence independent testing of the app and APIs.

What does a pre-launch penetration test cost for an Open Banking supplier?

UK day rates typically run £1,100 to £1,400. An API test is usually 4 to 6 days (£4,400 to £8,400), a mobile app test across iOS and Android 5 to 8 days (£5,500 to £11,200), and a combined mobile and API engagement 8 to 12 days (£8,800 to £16,800). Scope drives the exact figure; a scoping call produces a firm quote.

What assurance evidence should we have ready before due diligence?

Have four items ready: a recent independent penetration test report with a retest confirming fixes, your FAPI conformance position including any deviations, a software bill of materials for the app or SDK, and your secure development and vulnerability management policies.

Suppliers who can hand this pack over under NDA in the first round of questions typically avoid weeks of follow-up and shorten procurement noticeably.

Should we test just our SDK or the whole demonstration app?

Test the SDK inside a representative host app, not in isolation. Your customer’s security lead cares how the SDK behaves in a real integration: what it stores on the device, what it transmits, and what a hostile host app could extract from it.

Testing the SDK in isolation misses integration-boundary findings, which are exactly the ones that surface later in a customer’s own security review.

How long before launch should testing be booked?

Book at least six weeks before your launch or procurement deadline. A combined mobile and API engagement takes 8 to 12 testing days, your engineers then need time to remediate the findings, and the retest that produces shareable evidence needs its own slot in the calendar.

Leaving testing to the final fortnight usually means launching with open findings or slipping the date, and both are visible to your customer.

Walk into due diligence with the answers already written

If an Open Banking launch or a customer questionnaire is on the horizon, tell us about your app, SDK or APIs and we will map the journeys, confirm the day count and quote firmly, with UK-based testers at a CREST-accredited firm. Get a penetration testing quote and turn the security lead’s questions into a closed item.