Support for More Granular AIS Consent Scopes

[AlexandraHuzumMastercard]

Hi Team,

We are currently redirecting users to Lunar using the following authorization request scope query value in the redirect:
scope=offline PSP_AI

e.g. URL: https://auth.openbanking.prod.lunar.app/oauth2/auth?response_type=code&client_id=dummy-client-id&redirect_uri={{callback}}&scope=offline+PSP_AI&state=871a57a1-04d1-4f1e-bd31-9dfa204cb357

We have noticed that the consent screen presented to the PSU includes both:

Access your Lunar accounts
Access your transactions

For some of our use cases, we only require account details and/or balances and do not need access to transaction information.

Could you please confirm whether Lunar supports more granular AIS consent scopes or permissions that would allow us to request:
Account details only
Balances only
Transactions only
instead of always requesting access to both accounts and transactions?

If such functionality is supported, could you share the expected scopes or authorization parameters that should be used in the authorization URL?

Thank you for your assistance.

Kind regards,
Alexandra Ionela Huzum
Lead Product Manager-Technical,
Mastercard Open Finance

[arumie]

Hi @AlexandraHuzumMastercard

We have this on our road map, but sadly I can't give you a timeline for when we might get around to it.

I was wondering with regards to "Transactions Only". Currently that wouldn't be viable, because you need to have account IDs in order to fetch transactions. I can think of a few ways for us to solve this, but I was wondering what you would consider the best solution for this.

• having a transaction list endpoint which uses IBAN as selector?
• Having a transaction endpoint which fetches all transactions in one go?
• any other solutions?

Anything you guys having experience with working well for you guys with other banks that provide the "transaction only" scope?

[AlexandraHuzumMastercard]

Hello, @arumie !

For other providers, we typically have the ability to control the consent permissions requested from the PSU through parameters included in the redirect to the ASPSP. This is often achieved via a query parameter such as scopes, where we can specify the exact access required, for example: aisp_accounts, aisp_balances, aisp_transactions, or aisp_holder.

e.g. we may use in the query params for URL: scopes=aisp_accounts+aisp_balances => access only for accounts and balances.
scopes=aisp_accounts => just accounts.

If this can be enforced as part of the SCA process, that would be ideal. In such a setup, the bearer token would be limited to the permissions explicitly requested in the authorization URL. For example, if a token is authorized only for account information access, any attempt to use it for transaction data access would be rejected.

Thank you so much!