The proof still holds for the abstract model, but the real service can fail at TLS, OAuth, consent, redirect handling, session expiry, or third-party integration. That is why the assurance problem shifts from design correctness to runtime correctness. In regulated finance, the deployment is what customers use, so the live system must be tested continuously.
What breaks in the live system even when the proof still holds?
A formal proof answers a narrow question: whether the protocol satisfies its stated properties in the model. Once that protocol is deployed, the system can still fail at the boundaries where software, networks, browsers, and third parties interact. Continuous testing is what checks whether the deployed service still behaves like the model after real-world configuration, dependency, and timing effects are introduced.
That is why the breakage is usually not in the theorem itself, but in the assumption that implementation and deployment preserve the theorem’s conditions. In open banking, that gap matters because customer-facing correctness depends on live TLS, OAuth flows, consent state, redirect handling, and session behaviour, not only on abstract protocol logic.
Where runtime mismatch appears first
The first failures usually show up in protocol edge cases that are easy to idealise and hard to preserve in production. TLS termination, certificate handling, token audience checks, redirect URIs, session expiry, and consent lifecycles can all drift from the verified model if configuration or code changes are not exercised continuously.
For regulated finance, that drift is not cosmetic. If the live service rejects legitimate requests, accepts invalid ones, or desynchronises consent and authentication state, the customer experience and the control environment diverge. The result is a system that may remain formally sound on paper while becoming unreliable or unsafe in operation.
Teams that want a protocol-level reference point for live interoperability can anchor their deployment checks against the protocol’s registration and standards ecosystem, starting with the IANA registries and, where relevant, the IETF specifications that define the underlying internet behaviour.
Why continuous testing is part of assurance, not a separate nice-to-have
Formal verification helps at design time, but deployment assurance has to prove that the running service still respects the verified assumptions after releases, certificate rotations, partner changes, and browser or API updates. Continuous testing closes that gap by validating the system where customers actually interact with it.
That testing should cover the end-to-end path, not just unit-level happy cases. In practice, that means exercising authentication, consent capture, redirect continuity, token exchange, expiry handling, and third-party integration paths often enough to catch regressions before users or counterparties do.
For teams building on API and identity-heavy flows, the relevant failure modes align closely with known API and authentication control patterns. The OWASP API Security Top 10 is useful here because open banking implementations often fail at authorization boundaries, while NIST SP 800-63 Digital Identity Guidelines is a useful reference when identity assurance and authenticator behaviour need to be tested in a live flow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Open banking runtime failures commonly surface in OAuth and session handling. |
| Recommendation — Test live auth flows for token, redirect, and session regressions after every release. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The question hinges on live identity assurance and authenticator behavior in production flows. |
| Recommendation — Validate assurance levels and authenticator behavior against the deployed customer journey. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Continuous testing must catch credential, token, and expiry handling failures in operation. |
| AU-2 — Event Logging | Runtime correctness depends on observing failures in deployed protocol transactions. | |
| Recommendation — Re-test authenticator issuance, rotation, and expiry behavior in the live environment. Log end-to-end authorization and consent events to detect deployment drift quickly. | ||
| ISO/IEC 27001:2022 | A.8.29 — Security testing in development and acceptance | The subject is explicitly about testing the deployed service beyond formal design assurance. |
| Recommendation — Extend security testing into acceptance and post-change validation for the live service. | ||
Practitioner Guidance
What to verify: Treat the verified model as necessary but insufficient. Verify the deployed path from browser or app to consent, authorization, token issuance, and transaction completion under realistic timing, expiry, and retry conditions.
Implementation sequence: Start with smoke tests that cover TLS, OAuth, redirect handling, and consent state, then add regression checks for partner dependencies, certificate changes, and session expiry. The goal is to detect when production drift breaks an assumption the proof depended on.
Common mistake: Teams often test only the protocol handshake and miss stateful failures that appear later in the journey. A flow can authenticate successfully and still fail because the consent record, redirect chain, or third-party callback no longer matches the verified path.
Practitioner takeaway: In open banking, formal verification reduces design risk, but continuous testing is what preserves trust in the deployed service. If the runtime path is not being exercised, assurance degrades from evidence about the live system to evidence about an outdated model.