Skip to main content

Business & Technical Questions

For Service Providers​

Strategic / Business Questions​

Why should we move to Consent 3.0 now?

  • Consent 3.0 aligns the bLink ecosystem with modern open‑finance standards (FAPI 2.0).
  • It improves interoperability.
  • It enables cleaner user experiences and future‑proofs authentication and authorization flows.

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 a transition phase will exist, long‑term participation will require supporting Consent 3.0.

What are the expected business benefits for us as a Service Provider?

  • Reduced operational complexity through standardized flows.
  • Improved security posture without relying on custom solutions.
  • A unified experience for all SUs, reducing support and troubleshooting.

Budget & Planning Questions​

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

This depends on your current OAuth setup and internal architecture. Typical effort includes:

  • Supporting PKCE, PAR, and grant_id in the authorization server.
  • Adapting token lifecycle management.

bLink will provide guidance, readiness checks, and test environments.

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

  • Yes. A parallel operation phase is planned.
  • The exact sunset date for Consent 2.0 will be determined together with ecosystem participants.

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

Migration was postponed in 2025 due to results of a customer survey.

Technical & Integration Questions​

What are the technical differences compared to Consent 2.0?

  • Adoption of PKCE and PAR.
  • Removal of legacy elements like username validation.
  • More standardized OAuth / FAPI‑aligned error semantics.

How much change will be required on our API side?

It depends on your current implementation, but expect meaningful updates:

  • For the Token lifecycle.
  • Support for grant_id if used.

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

Yes.
bLink will provide:

  • A dedicated test / simulation environment.
  • Updated documentation.
  • A readiness / testing process.

Is Consent 3.0 backward-compatible?

  • No. Consent 3.0 introduces a redesigned token‑centric architecture.
  • However, Consent 2.0 and Consent 3.0 can run in parallel during the transition.

Risk & Compliance Questions​

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

  • No new risks are introduced.
  • Instead, Consent 3.0 reduces risk by adopting standard security mechanisms (PKCE, PAR, revocation).

How will the new model impact user authentication and security?

Security is strengthened:

  • PKCE protects against authorization code interception.
  • PAR ensures protected, tamper‑proof authorization initiation.

Overall, Consent 3.0 aligns with modern best practices for secure digital identity and access management.

For Service Users​

Business Value Questions​

What advantages does Consent 3.0 give us?

  • Standardized, predictable consent flows across all banks.
  • Reduced complexity (no proprietary or custom mechanisms).
  • Better alignment with international OAuth / FAPI standards.

Will it make onboarding easier for our end users?

Yes.
Consent flows become clearer, more consistent across banks, and easier to guide users through.
Standardized mechanisms also increase trust and reduce error cases.

Will all Service Providers support Consent 3.0?

Yes.
All bLink‑connected SPs are expected to adopt Consent 3.0 during or after the transition window.

Technical Questions​

What changes are required to consume Consent 3.0 APIs?

  • Implement PKCE in all authorization flows.
  • Use the PAR endpoint for authorization initiation.
  • Switch from permission-based flows to token‑based flows.
  • Update error handling for OAuth 2.0 / FAPI semantics.

Is there a transition period where both versions are supported?

Yes.
You will be able to operate both Consent 2.0 and Consent 3.0 in parallel, allowing a gradual migration.

Will we need to handle the refresh flow ourselves?

Yes.
Since Permissions are removed, bLink cannot implicitly trigger refreshes.
Service Users must perform refresh operations themselves as per OAuth standards.

Last updated on