Why open banking API testing is required before launch
Open banking API testing is the security assessment of account information and payment initiation APIs before they go live, and it checks whether an attacker or a careless integration can read data or move money without authorization. Teams usually commission it because a launch date is set, a bank or payment scheme partner asks for evidence during onboarding, an auditor wants proof for the scope of a compliance assessment, or an insurer requires documented testing before it will cover the service. The test covers the authorization server, the resource APIs, the client registration and token handling, the consent flows and the payment logic that sits behind them.
The risks fall into four groups that matter most to regulated firms. Token misuse occurs when access tokens are stolen, replayed or used by a client they were not issued to, which is why the FAPI 2.0 Security Profile, which became Final on 22 February 2025, requires pushed authorization requests, PKCE with S256 and sender-constrained tokens using mutual TLS or DPoP. Consent abuse happens when a third party keeps or extends access beyond what a customer approved, or when consent can be granted or changed without a clear record. Broken object-level authorization lets one customer's account identifiers or payment records be read or altered by another, a weakness that appears in the OWASP API Security Top 10 2023 as API1. Payment flow abuse covers the misuse of legitimate business operations at automated scale, which the same list describes as API6.
Before launch, confirm which FAPI 2.0 and consent requirements your scheme or bank partner has adopted, and ask the testing provider to map each test case to them. Ask whether the scope includes the OpenID conformance suite, which the OpenID Foundation provides free of charge for self-certification, and whether results will be delivered in a form your auditor can trace to each control. Decide early who owns the remediation backlog and who signs off retesting, because a launch decision often depends on closing high-severity findings rather than on the report alone.
What can be in scope for an open banking API test
An open banking test is only as useful as its boundaries. The components below connect through the same tokens, consents and gateways, so a scope that covers one without the others often misses the flaw that matters. Agree each item, the environment it runs in and the rules of engagement in writing before testing starts.
Account information endpoints
These resource endpoints return account balances, transactions and identity data under a consent granted by the account holder. Check that every request is bound to the consent's scope, account identifiers and expiry, and that one customer's consent cannot return another customer's accounts by changing an identifier. Confirm with the client which data classes and fields are in scope, since transaction history and personal data carry different handling rules.
Payment initiation endpoints
Payment initiation lets a third party create payment orders that move money, so these endpoints carry the highest business impact. Test whether payment details are bound to the consent and cannot be altered between authorization and submission, and whether limits, beneficiaries and duplicate-submission controls hold. Agree whether test payments may reach live payment rails or must stop at a simulator.
Authorization server and consent management
The authorization server issues tokens and records what each customer approved, including revocation. Scope the authorization endpoint, the pushed authorization request endpoint, token issuance, refresh and revocation, and the consent store that resource servers rely on. Confirm whether the FAPI 2.0 profile applies to your deployment, since it sets requirements for pushed authorization requests, PKCE and sender-constrained tokens.
Resource servers and object-level authorization
Resource servers enforce whether a caller may read or change a specific object, such as an account, payment or consent record. Scope every resource server that exposes customer data, and include bulk and search endpoints, which often return objects the single-object routes protect. Ask the client to provide two or more test customers so ownership checks can be exercised across accounts.
Client registration and third-party onboarding
Dynamic or manual client registration decides which third parties can obtain tokens, which redirect URIs they may use and which scopes they can request. Include the registration workflow, the software statements or certificates that identify each client, and the process for suspending a provider. Confirm whether registration runs in production, in a sandbox, or both, and who approves test clients.
Partner-facing gateways and environments
API gateways and partner portals sit between third parties and the core, so their routing, rate limiting, mutual TLS termination and logging affect the controls behind them. Decide whether the test runs against production, a pre-production copy with masked data, or a sandbox that mirrors production configuration. Write down the rate limits, test windows, data handling and escalation contacts, and confirm that any production testing has the client's sign-off.
How an open banking API engagement runs, phase by phase
The sequence moves from a written scope through architecture review, authorization testing and conformance checks to a report and a retest, so the client ends with evidence it can show its auditor, partner bank or regulator.
Agree scope and rules of engagement in writing
Before any testing, the client and DeployOpen agree in writing which APIs, environments, roles and consent flows are in scope, which account and payment test data may be used, and which actions are off limits, such as moving real funds. The client's API owner, security lead and, where relevant, the banking partner or TPP sponsor sign off. The step is done when the statement of work names the endpoints, the test identities, the testing window and the escalation contact. Confirm in the statement of work the duration, the number of testing rounds and any retest allowance, because these are not fixed here and depend on the written scope.
Review architecture and protocol flows
DeployOpen reviews the authorization server configuration, client registration, redirect handling, token lifetimes and the resource servers, and maps them against the FAPI 2.0 Security Profile, which requires pushed authorization requests, PKCE with S256 and sender-constrained access tokens using mutual TLS or DPoP. The review also covers how consent records are created, stored, revoked and bound to the payment or account resource. The output is a written flow map and a list of design questions for the client to answer, so that testing targets confirmed behavior rather than assumptions.
Test authentication and token controls
Testers check whether the authorization server and clients enforce the controls the design claims, including whether authorization requests must be pushed, whether PKCE is required and validated, whether tokens are bound to the client's key or certificate, and how redirect URIs and scopes are validated. Testing is performed with test accounts and approved client credentials, and findings are described by weakness category with reproduction detail limited to what the client's engineers need. The step closes when each control has a recorded result of pass, fail or not applicable, with evidence.
Test object-level and business flow authorization
Testers verify that each account information and payment initiation endpoint returns only the data tied to the consent granted, and that a consented party cannot read or change another customer's account, payment or consent record. They also examine business flow abuse, the category covered by API6 Unrestricted Access to Sensitive Business Flows in the OWASP API Security Top 10 2023, such as limits on repeated payment initiation, velocity controls and detection of automated misuse. The output is a set of authorization findings and a list of abuse scenarios, each tied to a control the client can change.
Run conformance checks against the OpenID suite
Where the implementation claims FAPI 2.0 conformance, DeployOpen runs the relevant tests from the OpenID Foundation's free conformance suite against the client's own deployment and records the results. Conformance results show whether the implementation meets the profile's requirements in those tests, which is separate from the security testing findings above. The client should confirm with the OpenID Foundation how self-certification is submitted and what a passing result is expected to look like for its chosen profile options before the suite is run.
Report findings and agree remediation
DeployOpen delivers a written report that rates each finding, explains the affected control and the business impact in the client's terms, and gives specific remediation guidance. The report is reviewed in a closing meeting where engineers can ask questions and agree which items will be fixed first. The step is complete when the client accepts the report and the remediation owners and target dates are recorded in the client's own tracker, since DeployOpen does not issue audit reports or attestations.
Retest fixes and close the engagement
Once the client reports fixes, DeployOpen retests the affected findings against the same flows and records whether each one is resolved, partly resolved or still open. The final retest report lists the closed items, any accepted residual risk with its owner, and the conformance results. Retest rounds and their scope should be stated in the statement of work, and the client should confirm how long it must keep the report and remediation records to meet its auditor's or regulator's evidence expectations.
How FAPI 2.0 controls are checked: PAR, PKCE and sender-constrained tokens
The FAPI 2.0 Security Profile sets a narrow, testable baseline for OAuth in financial APIs, and a tester's job is to confirm that each control is enforced by the authorization server and resource servers, not merely described in the design documents. The profile requires pushed authorization requests, so authorization parameters travel over a back-channel POST to the pushed_authorization_endpoint and the front-channel carries only a request_uri. It requires PKCE with the S256 method, and it allows only confidential clients. It also requires sender-constrained access tokens, bound either by mutual TLS or by DPoP. For each of these, the test question is the same: what does the server actually reject when the control is missing, malformed or replayed? Testers check this against the server's behavior, using the OpenID Foundation's conformance suite for the standard cases and targeted tests for the edges the suite does not cover, such as how the server handles a reused request_uri or a token presented under a different key. Before scoping, confirm with the client which profile version and deployment options (mTLS or DPoP) the authorization server claims to support.
The defensive intent is to make sure a stolen authorization code, a leaked access token or a misrouted front-channel request cannot be turned into a payment or account access by someone else. Evidence should show the control, the test performed, the observed server response and the configuration that produced it. For PAR, that means a record of rejected direct authorization requests and the server settings governing request lifetime. For PKCE, it means proof that code exchanges without a valid code_verifier fail and that the S256 method is enforced. For sender-constrained tokens, it means showing that a token presented without the matching certificate or DPoP proof is refused by the resource server, and that the resource server validates the binding, not just the token signature. Ask the testing provider to produce a control-by-control matrix with the conformance suite output attached, and to state which tests were run against production configuration versus a staging environment that mirrors it. Certification by the OpenID Foundation is self-certification of an implementation, so it should be presented to auditors as conformance evidence, not as an independent audit result.
Which weakness categories matter in open banking APIs
This table compares the weakness categories that testers look for in account information and payment initiation APIs, with what each looks like in this target and why it matters to the business. Read each row as a question to ask your provider about scope, and use the business impact column to decide which categories need the deepest testing first.
| Weakness category | What it looks like in this target | Why it matters to the business |
|---|---|---|
| Broken object-level authorization across accounts and consents | A token issued for one consent returns balances, transactions or payment records belonging to another account or customer by changing an account or payment identifier in the request. | Exposes customer financial data across accounts, which can trigger data protection duties and loss of trust in the open banking channel. |
| Consent scope and expiry failures | Endpoints accept access after consent is revoked or expired, or return data outside the permissions the customer granted, such as broader transaction history than authorized. | Third-party providers may keep accessing data the customer withdrew, creating regulatory exposure and disputes over authorized access. |
| Token binding and replay weaknesses | Access tokens or authorization codes work when presented by a party other than the original client, or can be reused after they should have expired or been consumed. | Stolen tokens could grant account access without the legitimate client, undermining the sender-constrained controls FAPI 2.0 expects. |
| Redirect and client registration flaws | Loose redirect URI matching, unvalidated client metadata, or registration paths that let unapproved clients obtain consent flows. | Authorization responses can be diverted to attacker-controlled endpoints, leading to account takeover or consent phishing. |
| Payment initiation integrity (amount, payee, idempotency) | The amount, creditor account or currency altered between consent and submission, or repeated submissions creating duplicate payments when retries occur. | Direct financial loss, misdirected funds and reconciliation failures that are costly to reverse and difficult to explain to customers. |
| Unrestricted access to sensitive business flows (OWASP API6) | Payment or account-linking flows can be called in high volume or automated sequences, such as repeated payment attempts, enumeration of payees or mass consent requests, without effective limits. | Fraud, abuse of payment rails and service degradation, even where each individual call is valid and properly authorized. |
How testing differs for account, payment and partner environments
Account information APIs return balances, transactions and account details for customers who have granted consent. Testing focuses on whether each request is limited to the accounts and data types the consent covers, and whether one customer's records can be reached by changing an account identifier or consent reference. Test data needs care because realistic transaction histories are personal financial data, so teams usually rely on synthetic accounts in a sandbox or on masked production-like records under agreed handling rules. Rate limits matter in two directions: tests must confirm that bulk retrieval is throttled, and testers must avoid triggering limits that degrade the service for real customers.
- Test data: Synthetic accounts with varied balances, currencies and transaction types, so authorization checks are exercised across account ownership boundaries.
- Object level authorization: Swapping account and consent identifiers across two test customers to confirm each response is bound to the correct grant.
- Rate limits: Confirming enumeration and bulk pulls are throttled, with agreed ceilings and a named contact on the provider side for any load-sensitive run.
- Sandbox versus production: Most account data testing runs in a sandbox, with production checks limited to read-only, non-invasive verification agreed in writing.
- Scope agreement: Confirm whether the provider's regulator or national scheme expects specific account data tests to be evidenced.
Before testing, confirm which consent scopes and data fields are in scope, and ask the provider how sandbox data mirrors production behavior.
Payment initiation APIs create payment orders that move money, so the risk profile is different from read-only data access. Testing focuses on whether payment requests are bound to the consent that authorized them, whether amounts, payees and currencies can be altered between consent and execution, and whether idempotency protects against duplicate submissions. Abuse of business flows is a central category here, covering excessive automated payment creation and misuse of payment limits. Test data must be fake payees and nominal amounts in a non-settling environment, because a test payment that settles in production is an incident.
- Business flow abuse: Reviewing how the provider limits repeated or automated payment creation, consistent with the OWASP API6 Unrestricted Access to Sensitive Business Flows category.
- Integrity of payment details: Checking that the amount, payee and currency approved by the customer are the ones submitted for execution.
- Idempotency and replay: Confirming duplicate requests do not create duplicate payments.
- Sandbox versus production: Payment tests should run in a sandbox with non-settling rails. Any production testing needs an explicit agreement covering payee accounts, limits and reversal handling.
- Scope agreement: Payment flows often need sign-off from the provider's operations and risk owners before any live-adjacent test.
Confirm with the provider which payment types, limits and settlement rails are reachable from the test environment, and who approves a test payment.
The authorization server issues the tokens and records the consent that every other API depends on. Testing covers the controls described in the FAPI 2.0 Security Profile, including pushed authorization requests, PKCE with S256, and sender-constrained access tokens using mutual TLS or DPoP. Tests also examine consent lifecycle behavior: how consent is shown, scoped, revoked and expired, and whether a revoked consent stops access to data and payments. Conformance testing against the OpenID Foundation suite is a useful baseline here, because it checks protocol behavior that manual testing often misses. Test data is mostly client registrations and test users, which is low risk, but token lifetimes and revocation timing need agreed windows.
- Protocol controls: Verifying PAR, PKCE and sender-constrained tokens behave as the profile requires, using the OpenID Foundation conformance suite as a baseline.
- Consent lifecycle: Testing revocation, expiry and scope narrowing, and confirming downstream APIs respect them.
- Token handling: Checking redirect URI validation, token reuse and session fixation within the authorization flow.
- Sandbox versus production: Authorization testing is generally safe in a dedicated environment with test clients. Production checks should be limited to configuration review.
- Scope agreement: Changes to client registration or signing keys in shared environments need the provider's change control.
Ask whether the provider has already run conformance tests and which profile version and certification status applies to its implementation.
Third-party providers that call an open banking platform are themselves a risk surface, because they hold client credentials, consent tokens and customer data. Testing covers how the provider registers and stores its keys, how it handles consent and token refresh, and whether its own integration can be abused to access accounts it should not reach. Scope is shared: the bank or platform owns its API, but the partner's client software and infrastructure may need separate agreement. Test data and environments depend on the partner's onboarding terms, and some partners will only accept testing that is coordinated through their own security contacts.
- Credential handling: Reviewing how client secrets or private keys are stored, rotated and revoked on the partner side.
- Partner-side consent handling: Checking that the partner requests only consented scopes and deletes or refreshes tokens according to its terms.
- Shared responsibility: Documenting which controls sit with the platform, which with the partner, and which with any cloud or hosting provider.
- Sandbox versus production: Partner onboarding sandboxes are the default. Access to live partner systems needs written authorization from both parties.
- Regulator or partner agreement: Where a regulator, scheme or partner must approve the scope, get that approval in writing before testing begins.
Confirm who owns each test target, who receives findings, and how the partner will be notified if a finding affects its systems.
Which frameworks expect open banking API testing
This table compares the frameworks that most often shape open banking API testing, what each asks for and the evidence an assessor or regulator will expect. Read each row against your licence type, the functions your APIs support and whether a Swift or PCI DSS service provider boundary applies. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports, attestations or certifications.
| Framework or requirement | What it expects for API testing | Evidence an assessor usually looks for |
|---|---|---|
| DORA Article 24(6) | Appropriate tests at least yearly on all ICT systems and applications that support critical or important functions, for financial entities other than microenterprises | A dated test plan covering the account information and payment initiation APIs, with results and remediation tracked to closure |
| DORA Article 25(1) | Test types including vulnerability scans, source code reviews where feasible, scenario-based tests and penetration testing | Evidence that each listed test type was considered for the API estate, with rationale where a type was not used |
| Delegated Regulation (EU) 2025/1190, Article 2(2) | Threat-led penetration testing for listed entities such as G-SII and O-SII banks, unless the authority's assessment says otherwise | Confirmation from the competent authority of whether TLPT applies, and a scope validated by that authority for live production systems |
| PCI DSS requirement 11.4.1 | Retention of penetration testing and remediation results for at least 12 months | Retained reports and remediation records covering the API environment, available on request |
| PCI DSS requirement 11.4.7 | Multi-tenant service providers support customers' external penetration testing, through evidence such as redacted reports or prompt customer access to test | Redacted reports showing testing of the subscribed infrastructure, or a documented process for customer test requests |
| FAPI 2.0 Security Profile | Pushed authorization requests, PKCE with S256, sender-constrained access tokens using mutual TLS or DPoP, and confidential clients only | Conformance test results from the OpenID Foundation suite and, where pursued, a self-certification record |
| Swift CSCF control 7.3A (advisory) | Penetration testing recommended to validate the operational security configuration of the Swift-related environment | Test scope and results tied to the Swift-related environment, reviewed against your own CSCF self-attestation |
What drives the cost and duration of an API security test
An open banking API test is priced by the surface it covers, the roles and consents it must exercise, and the depth of conformance and manual work involved. The cards below separate the components a buyer can control from the recurring costs that follow the first test.
Number of APIs and endpoints
The count of account information and payment initiation endpoints, plus their versions, sets the base effort. Ask the provider to list each API, its version and the endpoints in scope, and to state which are internal, partner-facing or open to third parties. Undocumented endpoints found during discovery usually add time, so ask how newly found endpoints are handled under the written scope.
Roles and consent types
Each combination of client type, user role, consent scope and payment type is a separate test path for object level authorization. A consent granted for account information should be refused for payment initiation, and a revoked consent should stop access. Ask how many consent types and customer journeys the quote covers, and whether tests run with several test accounts for each role.
Environments and test data
Testing against a sandbox, a pre-production environment or live production changes both the work and the risk. Production-like testing needs agreed test accounts, rate limits, transaction caps and a rollback plan. Confirm which environments are in scope, who provisions test accounts and what limits apply to payment flows so that testing does not move real funds.
Conformance and manual testing depth
Automated OpenID conformance runs are repeatable and do not replace judgment on consent screens, redirect handling, token lifetimes or business logic. The OpenID Foundation publishes a free conformance suite and a self-certification process for FAPI 2.0 implementations. Ask whether the quote covers running that suite, manual testing of abuse of payment flows, and how findings from both are reconciled.
Source code review where feasible
Reviewing authorization logic, token validation and consent enforcement in source code can find flaws that black-box testing misses. Access to code, build pipelines and developers adds coordination effort, so the quote should state which components are reviewed, whether the review is in scope, and what access the client must provide before work starts.
Retest and recurring testing
Retesting confirms that fixes for authorization and token findings work, and it is usually priced separately from the first test. Recurring costs include retainers for continuous or periodic testing, upgrades to new API versions and evidence retention for auditors. Ask what retest window is included, how long evidence is kept, and what a retainer covers between tests.
What your team prepares before the test starts
Start by assembling the access package, because most delays in open banking API testing come from missing credentials rather than from the test itself. Confirm with your engineering leads which sandbox or pre-production tenant will be tested, and request a dedicated test credential for each role the tester must exercise: an unauthenticated client, a confidential client registered for account information, a confidential client registered for payment initiation, and at least two end users whose accounts hold different balances and consent grants. For FAPI 2.0 implementations, the client registrations must match the profile's requirements, including confidential client type, pushed authorization request endpoints, and the sender-constrained token mechanism your authorization server uses, either mutual TLS or DPoP. Ask the tester to confirm which of these they need before the scoping call, since a missing registration can leave whole authorization flows untested.
Next, prepare the test data and consent records. Object level authorization testing depends on knowing which account identifiers, payment identifiers and consent identifiers belong to which test user, so give the tester a mapping sheet rather than expecting them to discover ownership by trial. Include the consent lifecycle states your platform supports, such as authorized, revoked and expired, and seed one consent in each state for each test user. Agree in writing whether test payments will settle in a sandbox ledger or a bank-side simulator, and whether any real counterparty account is ever touched. Name a technical contact who can explain the authorization server configuration and a business contact who owns the payment and consent journeys, and confirm both are available during the test window and the reporting period that follows.
Finally, coordinate change freezes and monitoring. If the test runs against any environment that shares infrastructure, databases or identity providers with production, agree a change freeze in writing and confirm the rollback and backup position beforehand. Tell your security operations team the test window, the source addresses the tester will use, and the test account naming convention so that alerts for brute force, token replay or unusual payment volume are recognized as expected activity and not escalated as incidents. Identify whether any regulator, scheme or partner must be notified before testing that touches production-adjacent systems, and ask your legal or compliance lead to confirm the position with your supervisor or partner contract. Under DORA, testing that involves live production systems is governed by the competent authority process, so confirm your obligations under Regulation (EU) 2022/2554 with your own compliance team before agreeing any such scope.
What to check when choosing an open banking testing provider
Open banking test providers vary widely in FAPI depth, engagement discipline and reporting quality. The cards below cover the checks that separate a provider who can test a live consent and payment flow safely from one who can only run a generic web scan.
Hands-on FAPI and conformance experience
Ask whether testers have worked against FAPI 2.0 Security Profile implementations, including pushed authorization requests, PKCE with S256 and sender-constrained tokens using mutual TLS or DPoP. Ask whether they have run the OpenID Foundation conformance suite against a real implementation, and what they did when a test failed. A provider who can explain the difference between a conformance pass and a security finding is usually the stronger choice.
Written scope before work starts
Require a written scope that names the APIs, consent and authorization endpoints, payment flows, environments and test accounts in play. Confirm whether the test covers account information, payment initiation or both, and whether it includes the authorization server, the resource server or the third-party provider interfaces. Work should not begin until both parties have signed the scope.
Rules of engagement for live systems
Open banking APIs often run against production or production-like data. Agree in writing which test accounts may be used, which payment limits apply, how abuse-style tests are throttled, and who can halt testing. Confirm the escalation contact and the procedure if a test triggers a fraud or monitoring alert at the bank.
Handling of customer data and credentials
Testers will see consent records, access tokens, client secrets and possibly personal financial data. Ask where evidence is stored, how long it is kept, who can access it, and whether real customer identifiers are masked in reports. Confirm that client credentials are rotated or revoked at the end of the engagement and that no test data leaves the agreed environment.
Report quality and reproducibility
A useful report states each finding, the affected endpoint or flow, the control that failed, the business impact on payments or consent, and a remediation direction an engineer can act on. It should separate confirmed issues from observations and record what was tested and what was not. Ask for a sample report before you commit.
Retest terms and their cost
Confirm whether a retest of remediated findings is included in the quote or billed separately, how long after the report it can be scheduled, and whether the retest covers the same scope. Clarify who verifies closure and how the retest result is documented for your auditor or regulator.
Separation of testing and attestation
A testing provider produces findings and evidence. An independent auditor or certification body issues assessment conclusions and certifications. Ask the provider to state in writing that it does not issue audit reports or attestations, and confirm which party your framework or regulator expects to review the results. Be cautious of any provider who offers a pass or certificate as part of the test itself.
Named testers and their roles
Ask for the names and roles of the testers, the lead, and the person accountable for quality review. Confirm their experience with the specific flows in scope, such as consent redirection, payment initiation and object-level authorization. Named roles make it clear who you will speak to when a finding needs clarification.
Common questions about open banking API testing cost and effort
What drives the cost of open banking API testing?
The cost follows the size and shape of the written scope: how many APIs, consent flows and authorization servers are in play, whether the test covers account information, payment initiation or both, and how many client types (confidential or otherwise) must be exercised. Testing against FAPI 2.0 controls such as pushed authorization requests, PKCE with S256 and sender-constrained tokens adds protocol analysis on top of standard API testing. Environment access matters too: test accounts, sandbox data, and whether production-adjacent systems must be handled with care. Ask any provider for a quote that lists each API, each flow, the environments, the test accounts required, and the retest allowance. Retesting after fixes is usually a separate line item, and ongoing testing is typically priced as a retainer.
How long does open banking API testing take and what sets the timeline?
Duration depends on the number of endpoints, the complexity of the consent model, the number of authorization server and client configurations, and how quickly test environments and credentials are provided. Conformance testing against the OpenID Foundation's suite can run in parallel with manual testing, but findings still need validation and remediation before a retest. DeployOpen does not publish fixed durations; the timeline is set in the written scope and agreed before work starts. Ask the provider to break the schedule into scoping, testing, reporting and retest windows, and to state which of those depend on your team, such as access provisioning or fix deployment.
What does the work need from our team?
Expect to supply a named technical owner, architecture diagrams for the authorization server and resource servers, API specifications, client registration details, and test accounts that mirror real consent journeys without holding live customer money. You will also need someone who can approve the rules of engagement, confirm which hosts and third-party connections are in scope, and agree how findings are escalated. For production-adjacent systems, your change and incident teams should know the test window. Engineers who own the consent and payment logic should be available to explain intended behavior, because many object-level authorization questions are design questions rather than defects. Confirm these responsibilities in the scope document so delays are visible early.
Can our own team run OpenID conformance tests without outside help?
Yes, in principle. The OpenID Foundation offers a free suite of conformance tests and a self-certification process for implementations, so an internal engineering team can run the suite against its own authorization server and clients. What the suite does not do is judge the surrounding design, such as consent screens, object-level authorization across account resources, or abuse of payment flows. Internal teams often run conformance early in development and then bring in an independent tester for adversarial testing before launch or audit. Check the current certification terms on the OpenID Foundation certification page before relying on any result for a customer or regulator, because requirements and program details can change.
Is production testing allowed for open banking APIs?
It depends on the regulatory context and what your own governance permits. Under DORA, threat-led penetration testing (TLPT) is performed on live production systems, with scope validated by the competent authority, and it applies only to entities that the authorities require to perform it under Delegated Regulation (EU) 2025/1190. For most other organizations, testing is run in a staging or pre-production environment that mirrors production configuration, with clear rules on data, rate limits and payment simulation. Where production-adjacent testing is needed, the written scope should define test accounts, time windows, stop conditions and the people who can halt the test. Never assume production access is permitted without written approval from your risk owner.
How often should open banking APIs be retested?
DORA Article 24(6) requires financial entities other than microenterprises to run appropriate tests at least yearly on all ICT systems and applications that support critical or important functions, so open banking APIs supporting such functions fall within an annual cycle. Retesting is also needed after material changes to the authorization server, consent model, client configuration or payment logic, and after significant findings are fixed. For payment gateway and tenant-facing components that fall under PCI DSS, the segmentation rules differ by role. Agree the retest cadence in writing, and ask the provider what a retest covers: only the fixed findings, or a broader regression of the affected flows.
Does the penetration test report satisfy an auditor?
A report helps an auditor, but it does not by itself certify compliance. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Ask the provider for a report that states the scope, the methodology, the test dates, the environments tested, each finding with severity and reproduction context at a defensive level, and the retest results. PCI DSS requirement 11.4.1 requires penetration testing results and remediation results to be retained for at least 12 months, so plan your evidence storage accordingly. Confirm early with your auditor which report format and evidence they expect.
How DeployOpen scopes, tests, reports and retests open banking APIs
DeployOpen approaches open banking API testing as a fixed-scope engagement, agreed in writing before work starts. We test account information and payment initiation APIs in the client's own environment, document each finding for engineering and assessors, and support retesting after remediation.
How we scope
- Written scope names the account information and payment initiation APIs, consent flows and authorization servers in play
- Scope records the OAuth and FAPI 2.0 controls expected, such as PAR, PKCE with S256 and sender-constrained tokens
- Scope confirms test accounts, sandbox or production-adjacent environments and any testing windows agreed with the bank or provider
How we build
- Test plan maps each API to its object level authorization, consent and business-flow risks, with abuse of payment flows covered
- OpenID Foundation conformance tests are run against the implementation, and results are recorded alongside manual testing
- Testing stays within agreed rules of engagement, with payment flows exercised using test data and agreed limits
How we hand over
- Report lists each finding with affected endpoints, evidence, risk rating and a remediation path engineers can act on
- Conformance results and control mapping are supplied so your team and assessors can trace each FAPI 2.0 control
- Results are retained so remediation evidence can be shared with auditors, regulators or customers as your framework requires
How we support
- Retesting confirms that remediated findings are closed, with the retest scope agreed in writing before it starts
- Ongoing support and continuous testing for open banking APIs are available as a retainer after the initial engagement
- Ask us to confirm which deliverables, retest rounds and support terms are included in your written quote
