The defects that pass every test.
The most serious flaw in a fintech API is an authorisation defect, and it passes every functional test because the request is well-formed. Here is how Flowmynt proves each boundary fails closed, and sweeps code and bundles for secrets.
- Industry
- Fintech
- Flowmynt product
- Security & Controls
- Deadline set by
- Your risk and disclosure obligations
- Stays with you
- Risk acceptance, disclosure, release approval
Broken object-level authorisation is the most common serious API flaw, and it passes every functional test. The request is valid, the response is correct, and it belongs to another customer.
Proving that a boundary holds means negative tests per endpoint and per identity, across accounts, tenants and roles. That is work nobody schedules, so it is the work that never happens.
Why functional tests miss it
An authorisation defect is account data disclosure. That is a regulator notification and a public one, not a patch note.
The boundary has to be proven, not assumed: every endpoint that accepts an object identifier must enforce an entitlement, and the proof must be repeatable when the API changes.
What you send us
The endpoints in scope, the ownership model each must enforce, and test identities spanning tenants and roles.
Each endpoint's entitlement becomes its acceptance criterion.
How the boundaries are proven
This is proof work, not feature work. The run enumerates every boundary, generates the attempts that should fail, runs them across real identities, and routes every finding to a fix and an independent review. Nothing is accepted until the boundary fails closed on re-run.
Enumerate
Every endpoint that accepts an object identifier is listed, with the entitlement it must enforce written against it.
Generate the negative suite
Cross-account and cross-tenant attempts are generated for each endpoint and identity, rather than written one at a time.
Run and sweep
The suite runs against a sandbox, and code, CI output and client bundles are swept for credentials and tokens.
Fix and review
Every finding goes to a fix on an isolated branch and an independent review before anything is staged.
Prove
Each boundary must fail closed on re-run before the item is accepted. The suite stays in your CI so the proof repeats.
Report
Entitlements enforced only in the interface are reported as risk for your decision, not patched over.
What you keep running
The suite is the deliverable. It lives in your CI, so the proof repeats every time the API changes rather than once at the end of an engagement.
- A negative-test suite tied to each endpoint and the entitlement it enforces, living in your CI.
- Reviewed fixes for every boundary that failed, each with the test that caught it.
- Entitlements enforced only in the interface, reported as risk rather than silently patched.
Your calls
Flowmynt finds and fixes. Whether a residual risk is accepted, whether a finding is disclosed and when a release ships are decisions for your risk owner, with the evidence in front of them.
- Risk acceptance.
- Disclosure and regulator notification.
- Production release approval.
Where this lives in Flowmynt
Flowmynt's own platform is built on the same rule: only allow-listed fields cross a boundary, every gate decision is written to a hash-chained audit trail, and secrets come from a secret store rather than code. The security page sets out how data is handled end to end.
For clients who build on Flowmynt's APIs, the same negative suite is part of the developer onboarding, so a new integration is proven at the boundary before it goes live.
Source pattern: API authorisation and secrets, Exekova fintech use cases
Has anyone proven the boundary?
Send the endpoints in scope and the ownership model. Flowmynt comes back with the enumerated entitlements and a plan to prove each one fails closed.
Talk to Flowmynt