User consent is the individual’s permission to share specific data or allow a defined use of that data. Authorisation is the control decision that determines what a system, provider, or application can actually do with that permission. In embedded finance, both must be aligned so that access is limited to the right data, the right purpose, and the right time.
Consent and authorisation solve different problems in embedded finance
Consent is the customer’s permission to share data or let a defined use happen. Authorisation is the system decision that enforces what the provider, app, or API can actually do with that permission. In embedded finance, the key distinction is that consent expresses intent, while authorisation constrains execution. They should be aligned, but they are not interchangeable.
The split matters because embedded finance often chains together a merchant app, a finance partner, and one or more APIs. A user may consent to connect an account or share a balance, but that does not mean the application may initiate payments, retrieve extra attributes, or reuse the data for another purpose. Good design keeps the permitted scope narrow and the enforced scope at least as narrow.
Consent is usually about purpose, scope, and revocation from the individual’s perspective. Authorisation is about policy, privilege, and access enforcement from the platform’s perspective. If the consent screen says “read-only account access” but the backend token can move money, the design has failed even if the UI looked correct. The security boundary lives in the enforcement layer, not in the wording of the consent prompt.
Why the distinction matters in payment and data flows
In embedded finance, consent commonly covers account linking, data aggregation, or a user-approved action. Authorisation covers whether the requesting application, service, or integration is allowed to perform that action at runtime. The same data flow can therefore require both: consent to use the data, and authorisation to limit which function may touch it. That is why policy scope, token scope, and purpose scope all need to match.
Practitioners should treat consent as a legal and product trust signal, not as a substitute for access control. An app can have valid consent from a user and still be forbidden from doing certain things by the provider’s policies or the API’s permissions model. This is especially important when the request is routed through intermediaries, because each hop may widen the blast radius unless it is explicitly constrained.
For teams designing these flows, the practical question is whether the consented action is the same as the authorised action. If not, the mismatch should be resolved before launch, not during incident response. The clearest way to avoid drift is to keep data categories, permitted operations, and token privileges mapped one-to-one wherever possible. Where that is not possible, the exception should be deliberate and reviewed.
How to tell when consent has been granted but authorisation is still too broad
Consent can be valid while authorisation is excessive. That happens when the user approved one purpose, but the integration holds broader entitlements than needed, such as write access instead of read access, access across multiple accounts instead of one account, or longer retention than the use case requires. In embedded finance, the most common failure is not missing consent, but overbroad runtime capability.
Another useful test is whether the control can be enforced after the consent is revoked. If revocation does not reliably remove the ability to call the API, use cached data, or continue a session, then the authorisation model is too weak. The right question is not only “did the user agree?” but “can the system still do what it should not do?”
That is why IAM and IGA Basics is a useful reference point for the underlying control logic, while Human vs Non-Human Identity helps explain where human permission ends and system-enforced access begins. For lifecycle control and revocation discipline, NHI Lifecycle Management Guide is a strong companion.
Risk and Threat Considerations
The main risk is scope creep, where a user’s consent is narrower than the permissions held by the connected application or service. That can expose extra account data, enable unauthorised actions, or allow continued access after the original purpose has ended. In embedded finance, the harm often comes from an apparently legitimate integration being able to do more than the user intended.
Failure mechanism: Consent is accepted at the product layer, but the backend token, API permission set, or service policy is broader than the approved use, so access persists beyond the intended scope.
Impact: The result can be data overexposure, unauthorised payment initiation, weak revocation, and a larger blast radius if the integration is abused or compromised.
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 and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Authorisation in embedded finance depends on limiting runtime permissions to the approved scope. |
| IA-5 — Authenticator Management | Consent and authorisation both rely on secure handling of tokens and related access material. | |
| AC-3 — Access Enforcement | The question turns on the difference between permission granted and access actually enforced. | |
| Recommendation — Enforce least privilege so the API can only perform the user-approved finance action. Manage token lifecycle tightly so revoked consent cannot keep granting access. Enforce access decisions at the service boundary, not in the consent screen alone. | ||
| OWASP ASVS | V8 — Authorization | Embedded finance flows need correct runtime authorization beyond user consent. |
| Recommendation — Verify that every finance action is authorized against the exact permitted scope. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | APIs can expose finance operations that exceed the consented use case. |
| API1 — Broken Object Level Authorization | Consent does not prevent overbroad access to specific customer accounts or records. | |
| Recommendation — Restrict each endpoint to the exact function the caller is allowed to invoke. Check object-level access so a consented session cannot reach another user’s data. | ||
Practitioner Guidance
What to verify: Check that the user-facing consent scope, the API permission scope, and the operational token scope describe the same action set. If any one of them is broader, treat that as a control defect rather than a wording issue.
Decision rule: If revocation does not immediately remove the ability to perform the approved action, the design is too permissive and should be corrected before relying on the consent flow in production.
Practitioner takeaway: In embedded finance, consent is about permission to proceed, but authorisation is what prevents the system from exceeding that permission. The safer design is the one where the backend can never do more than the user agreed to.
