Skip to main content
Not Yet Active - For Information Only

This page provides information about the planned Consent Management 3.0. It is not yet live - the content is intended to support orientation and decision-making, is subject to change and should not be considered final.

Consent Management 3.0

In today's open banking ecosystem, financial institutions face the critical challenge of sharing customer data with third-party providers while maintaining security, trust, and regulatory compliance. Consent management serves as the cornerstone of this data-sharing framework, enabling banks and financial institutions to:

  • Protect customer interests and maintain trust in an increasingly open financial ecosystem
  • Meet regulatory requirements for data privacy and customer protection
  • Enable innovation through secure third-party integration
  • Maintain control over data access while supporting customer choice
  • Mitigate risks associated with unauthorized data access

The stakes are particularly high for financial institutions because:

  • They handle highly sensitive financial data that could lead to direct monetary loss if compromised
  • They operate in a heavily regulated environment where consent-related violations can result in significant penalties
  • Their reputation and customer trust depend on demonstrating strong data governance
  • They must balance security with the seamless customer experience expected in modern financial services
  • Basically, consent management is the explicit expression of the customer's will that something may be carried out in their name. In a sense, consent is an authorization (in which the intentions and consequences are made explicitly clear to the customer). In OpenBanking, where TPPs are in place in addition to FIs, a basic consent is the question to which extent a TPP may access customer data at the FI: Who is allowed to access what (service / data) for how long? How to revoke a given consent?

This page covers the motivation, impact, and technical implementation of Consent 3.0

With evolving security threats and increasingly complex user journeys, it is essential to keep our authorization framework up to industry standards. Consent 3.0 is an initiative to push towards the FAPI 2.0 Security Profile, implicitly bringing significant security, usability, and interoperability improvements to our API. With this step, we hope to reduce integration efforts for both parties by moving closer to industry wide standards and also enable Service Users operating in Switzerland and abroad to use the same consent model.

What exactly has changed?​

Here is the comprehensive list of changes:

  • Introduction of Swiss FAPI 2.0 Security Profile
    • PKCE becomes mandatory.
    • Implementation of Pushed Authorization Requests (PAR).
    • Implementation of Grant management to natively support multiple consents.
  • Fine-grained access control for Service Users and efficient management of existing grants.
    • Token/Grant Revocation endpoints become mandatory (to improve token lifecycle management):
    • Token Revocation endpoint according to [RFC7009]
    • Grant Revocation endpoint according to [oauth-v2-grant-management-03]
  • Eliminate bLink legacy features as far as possible (username validation)

Benefits​

In this paragraph, we want to have a closer look at the potential benefits.

For Service Users​

  1. Better end-user experience through Grant Managements
    • Provides a consistent way to manage multiple concurrent grants of an end-user
    • Already given grants can be modified. E.g. the Service User can ask the end-user to give access to additional resources without creating an new grant.
    • Consent initiation becomes more predictable and standardized.
    • Standardized Grant Management allows Service Users to manage user consents consistently and fine-grained.
  2. Improved default Security
    • PAR + PKCE reduces the need for proprietary security solutions.
    • PKCE ensures protection against code interception threats, with no extra integration effort beyond compliance.
    • PAR guarantees secure delivery of authorization details over a MTLS protected connection between Service User and Service Provider, removing risks tied to URL tampering or leakage.
    • Service users are guaranteed to be able to revoke tokens (/revoke endpoint becomes mandatory).
  3. Better Developer Experience
    • Developers benefit from cleaner, well-documented flows that align with the latest OAuth 2.1 standards, reducing time to market.
    • Fewer deviations from the standard reduce operational complexity, freeing resources to focus on product innovation.

For Service Providers​

  1. Reduced Risk & Attack Surface
    • PKCE and PAR close known attack vectors in OAuth 2.0 without relying on custom security layers. PKCE and PAR mitigate key OAuth 2.0 vulnerabilities without relying on custom security layers.
    • Enhanced granularity in Grant Management supports better monitoring and enforcement of user consent lifecycles.
  2. Operational Efficiency & Lower Maintenance
    • Standardization allows reuse of common components across services.
    • Regulatory alignment with standards like FAPI becomes easier to demonstrate.
  3. Improved Ecosystem Consistency
    • Banks can deliver a uniform API experience to all Service Users, minimizing support requests.
    • Easier Onboarding of new Service Users thanks to common understanding, standardized flows, and documentation.
  4. Grant Management serves as a foundation for new use cases not yet possible today
    • Grant Management together with rich authorization requests will allow for fine-grained authorization requests that enable powerful new use cases beyond simple access requests. (RAR decision will still need to be made by SFTI).
  1. Simplifying Onboarding
    • By moving closer to industry standards, we reduce the learning curve and improve interoperability with off-the-shelf solutions.
  2. Predictable Behaviour
    • Standard OAuth flows behave consistently across different implementations, making troubleshooting more straightforward and reducing support costs.
  3. Future-Proofing
    • Following industry evolution ensures the platform remains compatible with emerging standards and tools.

Potential Impact​

The transition to Consent 3.0 will have implications for all participants in the bLink ecosystem. In the following sections, we outline the key areas where Service Users and Service Providers will need to adapt their systems, processes, and implementations to support the new OAuth 2.1 and FAPI 2.0 standards along with enhanced grant management capabilities.

For Service Users​

  1. Required Migration Effort

    • Migration of existing permissions to tokens.
    • Update existing integrations to work with new authorization flows.
    • Testing and validation of migrated functionality.

  2. Required Implementation Effort

    • Refresh flow with the move away from permissions, it is now the responsability of the service user to implement the refresh flow.
    • PKCE Integration: Implement PKCE for all authorization code flows to enhance security.
    • PAR Adoption: Switch from direct authorization requests to using PAR endpoint for initiation.
    • Grant Management: Implement native support for multiple consents per user.
    • Error Handling: Adapt error handling for new OAuth 2.1 and FAPI 2.0 flows.

For Service Providers​

  1. Required Implementation Effort

    • Multi-Token Support: Support multiple tokens per end user, respectively e-banking contract.
    • PKCE Validation: Server-side implementation of PKCE parameter validation and verification.
    • PAR Endpoint: Development of new PAR endpoint for secure authorization request handling.
    • Grant Management APIs: Implementation of grant lifecycle management endpoints (e.g list, query).
    • Migration Endpoint: Still to clarify, but might be needed to migrate Non-CaaS Tokens.
    • Consent Page: Changes in the frontend will need to be made to support Grant Management.

  2. Infrastructure and Operations

    • Enhanced monitoring and logging for grant lifecycle events.

  3. Migration and Compatibility

    • Coordinated rollout strategy with ecosystem participants.

Important Note: The full extent of implementation requirements is still being finalized as the Consent 3.0 specification evolves. Additional requirements may emerge during the specification review phase, and implementation complexity may vary based on current system architecture and existing OAuth implementations.

Migration approach​

In the image below, you can see what a roadmap for Consent 3.0 could look like. Please note that the provided roadmap is just a possible approach and not a fixed proposal.

Multiple tokens 1 The implementation follows a structured five-phase approach to ensure smooth transition across the entire blink ecosystem:

Phase 1: Specification & Review

  • Finalize OAuth 2.1 and FAPI 2.0 specifications for bLink.
  • Stakeholder review and feedback incorporation.
  • Technical specification validation.
  • Impact assessment and communication to ecosystem participants.

Phase 2: Bring it to the Test environments

  • Deploy Consent 3.0 capabilities in test environment.
  • Comprehensive testing of new features (PKCE, PAR, Grant Management).

Phase 3: Development by Platform Participants

  • Service Providers implement Consent 3.0 support.
  • Service Users develop migration plans and update integrations.
  • Parallel development and testing by ecosystem participants.
  • Technical support, readiness check, and guidance provided by bLink platform.

Phase 4: Migration Window

  • Coordinated migration of existing integrations.
  • Legacy system deprecation planning.

Phase 5: All Participants Migrated

  • Complete ecosystem migration to Consent 3.0.
  • Legacy feature removal.
  • Enhanced security and standardization across the platform.

Technical Implementation​

This section provides detailed technical specifications for implementing Consent 3.0.

The technical implementation centers around three key components:

  • Migration Flow: Service Users will have to exchange their permissions for access/refresh tokens.
  • Consent 3.0 Flow: Including PKCE, PAR, and OAuth 2.0 Authorization Code Grant flow.
  • Grant Management: Supporting multiple consents and fine-grained access control.

These technical specifications build upon the business requirements and benefits outlined in the previous sections, providing the concrete implementation details necessary for successful migration to Consent 3.0.

Migration Flow​

Security Note

During the migration process, the original bank tokens stored at the bLink platform are not exchanged or exposed. Instead, bLink generates new access and refresh tokens specifically for the Service User. This ensures that the underlying bank credentials remain secure and isolated within the bLink platform, maintaining the same security and regulatory boundaries as Consent 2.0.

The migration from Consent 2.0 to Consent 3.0 enables Service Users to seamlessly transition their existing permissions to a token-based system. This process allows Service Users to continue accessing Service Provider APIs without requiring end-users to re-authenticate or re-consent.

The migration flow consists of two main phases:

  1. Permission to Token Migration: Service Users exchange their existing permission IDs for access and refresh tokens through the migration endpoint on the consent 3.0 API.
  2. Token Refresh Flow: Service Users can refresh expired access tokens using the refresh tokens obtained during migration.

This approach ensures continuity of service while leveraging the enhanced security and capabilities of the Consent 3.0 framework. The following sequence diagram illustrates the complete migration and token refresh process for Consent-as-a-Service. We will provide additional information for the CF2 Flow.

The following chapters show the new Consent 3.0 Flow.

High-level Flow Description​

The Consent 3.0 flow can be roughly divided into the following phases:

  • Preparation.
  • Pushed Authorization Request.
  • OAuth 2.0 Authorization Code Grant flow.

Detailed Flow Description​

See current status at ca-security

Grant Management​

Grant management is based on the Grant Management for OAuth 2.0 specification.

Use case overview​

The following grant management cases to be supported on bLink (final decision according to Swiss FAPI Security Profile)

  • create
  • query
  • revoke
  • update
  • replace

The implementation of Grant Management has implications on the bLink directory to document support and the specifics of grant management by the Authorization Server, see section 7.1 Authorization server's metadata

Creating grants​

In Consent 3.0 grants are created implicitly in the context of the Pushed Authorization Request.

Updating or replacing grants​

An existing grant can be updated or replaced. Technically this can be done in two ways:

  1. implicitly by executing the Consent 3.0 flow another time
  2. explicitly by posting to a Grant Management endpoint (to be implemented by bLink and the SP)

The conditions under which it is allowed to modify a grant by posting the modified grant to the respective endpoint is to be defined by the Business API owner.

The following use case describes the steps of RO, SU and SP to modify an existing consent by executing another Consent 3.0 flow.

When the Consent Flow 3.0 is executed another time with grant_management_action = merge or replace, then an existing consent is updated by combining the existing grant with the new one, or gets replaced completely.

The RO would like to modify the scope of an existing consent between the SU and the SP.

  1. RO selects consent to be modified at SU.
  2. SU creates a PAR with the consent_id of the selected consent.
  3. SU sends PAR via bLink to SP (step A).
  4. SP checks if a consent with the consent_id of the PAR already exists (step I). If this is the case, the SP loads the consent and presents it to the RO (step J).
  5. RO changes scope of consent, stores and signs the consent at the SP (step 12-15). Open question to SPs: Will the existing signature be overwritten or will an additional signature be saved? Is this specific for each SP?
  6. SP creates authorization code and redirects back to SU.
  7. SU requests tokens (step 18).
  8. SP invalidates the old tokens, issues new ones and returns them to the SU (step 21).
  9. SU replaces the old tokens associated with the consent_id with the new ones (step 22).

Example of implicitly replacing grant (by PAR):

POST /oauth/push-auth-endpoint/b-link/v3/par
host: api-cert.six-group.com

response_type=code
&client_id=654321
&redirect_uri=httpsapi-cert.six-group.com/oauth/authresponse
&scope="urn:blink:xs2a:ais urn:blink:xs2a:pss:write"
&state=d60dbae3-b1b2-419c-bc72-1054fab294ec
&code_challenge=JPaMZZhWRl4uceYCpN4QV9RFOHV4tlrD-lCUqDUsEh4
&code_challenge_method=S256
&provider_id=99999
&username=john.doe@acme.com
&grant_management_action=replace
&grant_id=TSdqirmAxDa0_-DB_1bASQ
&consent_name="My multi-banking consent"

Querying grants​

Grants may easily be queried.

Example request:

GET /grants/{grant_id} HTTP/1.1
x-corapi-target-id: 99999
host: api-cert.six-group.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

Example response (see "6.4 Query Status of a Grant"):

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Type: application/json

{
   "scopes":[
      {
         "scope":"contacts read write",
         "resources":[
            "https://rs.example.com/api"
         ]
      },
      {
         "scope":"openid"
      }
   ],
   "claims":[
      "given_name",
      "nickname",
      "email",
      "email_verified"
   ],
   "authorization_details":[
      {
         "type":"account_information",
         "actions":[
            "list_accounts",
            "read_balances",
            "read_transactions"
         ],
         "locations":[
            "https://example.com/accounts"
         ]
      }
   ]
}

Revoking grants​

A new endpoint must be implemented:

DELETE /grants/{grant_id}

Example request:

DELETE /grants/TSdqirmAxDa0_-DB_1bASQ HTTP/1.1
Host: as.example.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

Example response:

HTTP/1.1 204 No Content

See current status at ca-security

Resources​

FAQ​

For Service Provider​

Strategic / Business Questions​

Why should we move to Consent 3.0 now?

  • Consent 3.0 brings the bLink ecosystem in line with modern open finance standards (OAuth 2.1, FAPI 2.0), addressing known security gaps and enabling better interoperability and user experience.

Will Consent 3.0 be mandatory, or can we choose not to adopt it?

  • Consent 3.0 will become the new standard for the bLink platform. While there will be a transition phase, long-term participation in the ecosystem will require support for Consent 3.0.

What are the expected business benefits for us as a bank?

  • Reduced operational effort through standardized flows

Improved security posture without relying on custom solutions

  • Unified experience for all TPPs, reducing support requests
  • Easier regulatory reporting and auditability

Budget & Planning Questions​

What investment (resources/costs) is required to implement Consent 3.0?

This depends on your current OAuth implementation and system architecture. Key efforts include:

  • Implementing PKCE, PAR, and Grant Management, Adjusting Authorization Servers.
  • Setting up token and grant revocation endpoints: bLink will provide guidance, readiness checks, and test environments to support the transition.

Will Consent 2.0 be supported in parallel – and for how long?

  • Yes, a parallel phase is planned. The exact end date for Consent 2.0 support will be coordinated with participants and depends on the timeline for transition to Consent 3.0.

Is there a clear migration timeline so we can align our budgeting cycle?

As of July 2025, SIX is conducting a consultation phase with the bLink community to gather input on preferred timelines and implementation priorities. The final migration timeline will be defined and communicated based on the outcome of this consultation, allowing participants to align their internal planning and budgeting accordingly.

Technical & Integration Questions​

What are the technical differences compared to Consent 2.0?

  • Introduction of PKCE and PAR
  • Native support for multi-grant scenarios (multiple consents per user)
  • Mandatory grant/token revocation endpoints
  • Elimination of legacy bLink elements like username validation

How much change will be required on our API side?

This depends on your current setup, but the changes are not to be underestimated: new endpoints, token lifecycle handling, and grant management features need to be implemented.

Will there be support tools or a testing environment to ease integration?

Yes. bLink will offer a test/simulation environment, documentation, and a readiness check process to support integration and certification.

Is the Consent 3.0 model backwards-compatible?

No. Consent 3.0 introduces a new token-based architecture. However, both Consent 2.0 and 3.0 can be supported in parallel during the transition phase.

Risk & Compliance Questions​

Are there new risks we need to mitigate (e.g. data misuse, longer validity)?

On the contrary, Consent 3.0 reduces risk through established security mechanisms like PKCE and PAR.

How will the new model impact user authentication and security?

Security is significantly improved:

  • PKCE protects against code interception
  • PAR ensures tamper-proof authorization initiation

Token and grant revocation endpoints provide precise lifecycle control

Overall, Consent 3.0 aligns with the latest best practices in secure digital identity and access management.

For Service User​

Business Value Questions​

What advantages does Consent 3.0 give us?

  • Predictable and standardized consent flows
  • Reduced complexity (no need for custom security solutions)
  • Granular and manageable multi-consent support
  • Better alignment with international standards (OAuth, FAPI)

Will it make onboarding easier for our end users? Yes. Consent flows are cleaner, more consistent, and easier to guide end users through. The use of familiar security concepts improves usability and trust.

Will all banks support Consent 3.0? Yes, all bLink-connected banks are expected to support Consent 3.0 during or after the transition period.

With Consent 3.0, will all Service Providers be supporting multi-consent? Yes. With Consent 3.0, support for managing multiple active consents (grants) per end user is a mandatory requirement for all Service Providers. This ensures consistent behavior across the ecosystem and enables more flexible and user-friendly consent experiences for Service Users and their customers.

Technical Questions​

What changes will we need to make to consume Consent 3.0 APIs?

  • Implement PKCE in your authorization flows
  • Switch to using the PAR endpoint
  • Integrate grant management logic
  • Adapt to token-based access instead of permission IDs
  • Update error handling for OAuth 2.1/FAPI flows

Is there a transition period where both versions are supported?

Yes. A transition window will allow you to run both Consent 2.0 and 3.0 integrations in parallel, easing the rollout and testing phases.

Will we need to do the refresh flow ourselves?

Yes. Due to the switch away from PermissionIds, bLink is no longer able to trigger the refresh implicitly.

Operational / Risk Questions​

How can we verify whether a bank supports Consent 3.0 or not during the transition phase? bLink will maintain a directory of supported versions per bank. This allows TPPs to dynamically detect and route to the appropriate flow.

Last updated on