Fintech
The challenge
Regulated financial services face authorization requirements that traditional IAM was never designed to handle:
- Regulatory mandates for delegated access — open banking and open finance require fine-grained, consent-based data sharing between institutions. Each regulatory framework has its own requirements.
- Each partner is a custom project — connecting a new fintech application to bank APIs means months of custom authorization work. Scaling to dozens of partners means dozens of custom integrations.
- Consent is captured but not enforced — customer consent is a database record, not a policy-enforced authorization constraint. The gap between "consent was given" and "consent is enforced at the moment of access" is where compliance risk lives.
- Audit for regulators is expensive — reconstructing who accessed what customer data, through which partner, under what consent, is a manual and error-prone process.
- Transaction-level authorization — some operations (payment initiation, KYC verification) require step-up authentication or additional consent at the moment of access, not just at login.
How PBAC handles it
Standards-based authorization for regulated data sharing
OAuth 2.0 with resource indicators (RFC 8707) and Rich Authorization Requests (RFC 9396) gives you fine-grained, consent-aware access tokens. A fintech application accessing customer account data gets a token scoped to exactly the accounts and operations the customer authorized — not a broad API key.
Dynamic client registration for partner onboarding
New partner institutions register their applications via software statements with policy-governed entitlements. Onboarding a new fintech partner is a registration event with constrained scopes — not a custom integration project.
Consent as a policy obligation
Customer consent is enforced as a policy-driven obligation at token issuance and re-evaluated at every introspection. If a customer revokes consent, the next API call is denied — without touching the partner application or the bank's API.
Complete audit trail for regulators
Every access decision is logged with the subject, the resource, the action, the consent authority, and the policy outcome. Regulatory audit is a query against structured data, not a reconstruction from scattered logs.
Architecture
Resource types and scopes
| Resource | Type URI | Scopes |
|---|---|---|
| Account | urn:fintech:account | read, manage |
| Transaction | urn:fintech:transaction | read, initiate |
| Payment | urn:fintech:payment | read, initiate, reverse |
| KYCDocument | urn:fintech:kyc-document | read, submit, verify |
| Report | urn:fintech:report | read, export |
Scope-resource binding: Scopes are grouped under resource types in granted_resources. read for Account is in the grant for urn:fintech:account. initiate for Payment is in the grant for urn:fintech:payment. No cross-resource leakage.
Resource servers
| RS | Resource Indicator | Types Served |
|---|---|---|
| Core Banking API | https://api.bank.example.com/accounts/* | Account, Transaction |
| Payments API | https://api.bank.example.com/payments/* | Payment, Transaction |
| KYC API | https://api.bank.example.com/kyc/* | KYCDocument |
| Regulatory Reporting API | https://api.bank.example.com/reports/* | Report |
Trust issuers
- https://trust.bank.example.com — Bank app registry
- https://regulator.example.com — Regulator-approved apps
Client apps and entitlements
| App | Type | granted_resources |
|---|---|---|
| Mobile Banking | confidential_app | urn:as:userinfo (openid); account, transaction, payment with scopes; resource_indicators for accounts/, payments/ |
| Merchant Gateway | confidential_app | urn:as:userinfo (openid); payment, transaction with scopes; resource_indicators for payments/, accounts/ |
| KYC Portal | confidential_app | urn:as:userinfo (openid); kyc-document: read, submit; resource_indicator for kyc/* |
| Regulatory Dashboard | confidential_app | urn:as:userinfo (openid); report, account with scopes; resource_indicators for reports/, accounts/ |
Key flows:
- Mobile Banking: account.read, transaction.read, payment.initiate
- Merchant Gateway: payment.initiate, transaction.read
- KYC Portal: kyc-document.submit, kyc-document.read
- Regulatory Dashboard: report.read, report.export, account.read (audit)
Example token requests
Mobile Banking — initiate payment:
scope=openid initiate
resource=https://api.bank.example.com/payments
resource_types=urn:fintech:payment
Merchant Gateway — read transaction:
scope=openid read
resource=https://api.bank.example.com/accounts/transactions
resource_types=urn:fintech:transaction
KYC Portal — submit document:
scope=openid read submit
resource=https://api.bank.example.com/kyc/documents
resource_types=urn:fintech:kyc-document
Regulatory Dashboard — export report:
scope=openid read export
resource=https://api.bank.example.com/reports
resource_types=urn:fintech:report
Policy implementation note
The token policy uses the unified model: granted_resources (array of { type, scopes, resource_indicator? }). Resource-scoped scopes require resource_types in the request. Policy evaluates via oauth.entitlements.client_is_allowed.
Try it
See this model in action with the Quickstart — from credentials to a policy decision in 5 minutes.
Want to discuss how PBAC fits your environment? Talk to us →
Next steps
- Quickstart — From credentials to a policy decision in 5 minutes
- Consent Extension — Implement consent-as-obligation for delegated access flows
- Registering Software — Dynamic client registration for partner onboarding