Create Consent

post https://test-api.tbcbank.ge/xs2a-sandbox/v2/consents/account-access

This method create a consent resource, defining access rights to user accounts. These accounts are addressed explicitly in the method as parameters as a core function.

Side Effects
When this consent request is a request where the "recurringIndicator" equals "true", and if it exists already a former consent for recurring access on account information for the addressed PSU, then the former consent automatically expires as soon as the new consent request is authorised by the PSU.

Optional Extension:
As an option, an ASPSP might optionally accept a specific access right on the access on PSD2 related services for all available accounts.

As option an ASPSP might optionally also accept a command, where only access rights are inserted without mentioning the addressed account.
The relation to accounts is then handled afterwards between PSU and ASPSP.

As a last option, an ASPSP might in addition accept a command with access rights

to see the list of available payment accounts or
to see the list of available payment accounts with balances.

Body Params

access

object

required

Requested access services for a consent.

recurringIndicator

boolean

required

"true", if the consent is for recurring access to the account data. "false", if the consent is for one access to the account data.

validTo

date

required

This parameter is defining a valid until date (including the mentioned date) for the requested consent.

Max value for this field is 90 days.
If date is provided more than 90 days, it will be decreased to 90 days.
Less than 90 days, will remain same as provided date.

frequencyPerDay

int32

required

This field indicates the requested maximum frequency for an access without PSU involvement per day. For a one-off access, this attribute is set to "1". The frequency needs to be greater equal to one. If not otherwise agreed bilaterally between TPP and ASPSP, the frequency is less equal to 4.

Headers

X-Request-ID

uuid

required

ID of the request, unique to the call, as determined by the initiating party.

Digest

string

required

Is contained if and only if the "Signature" element is contained in the header of the request.

X-JWS-Signature

string

required

A signature of the request by the TPP on application level. This might be mandated by ASPSP.

PSU-ID

string

Identity number of user to identify client in ASPSP systems.

PSU-Corporate-ID

string

Identity number of corporate user to identify corporate client in ASPSP systems.

PSU-IP-Address

string

required

The forwarded IP Address header field consists of the corresponding HTTP request IP Address field between PSU and TPP. It shall be contained if and only if this request was actively initiated by the PSU.

Accept-Language

string

HTTP header indicates the natural language and locale that the client prefers.

TPP-Redirect-URI

uri

required

URI of the TPP, where user will be redirected to after accepting consent.

TPP-Explicit-Authorisation-Preferred

boolean

If it equals "true", the TPP prefers to start the authorisation process separately.
If it equals "false" or if the parameter is not used, there is no preference of the TPP.
This especially indicates that the TPP assumes a direct authorisation of the transaction in the next step.

TPP-Redirect-Preferred

boolean

If it equals "true", the TPP prefers a redirect SCA approach.
If it equals "false", the TPP prefers not to be redirected for SCA. The ASPSP will consider the Decoupled SCA approach, depending on the parameter TPP-Decoupled-Preferred.

The parameter is required to be false, if TPP prefers to use decoupled SCA aproach and TPP-Decoupled-Preferred is "true".

If the parameter is not used, ASPSP will consider Redirect SCA Approach.

TPP-Decoupled-Preferred

boolean

If it equals "true", the TPP prefers a decoupled SCA approach.
If it equals "false", the TPP prefers not to use the decoupled approach for SCA. The ASPSP will consider redirect as SCA approach.

The parameter is required if TPP prefers to use decoupled SCA aproach.

If both parameters TPP-Redirect-Preferred and TPP-Decoupled-Preferred are present and true, the request is still not rejected and ASPSP will consider Redirect SCA Approach.

PSU-IP-Port

string

The forwarded IP Port header field consists of the corresponding HTTP request IP Port field between PSU and TPP, if available.

PSU-Geo-Location

string

The forwarded Geo Location of the corresponding http request between PSU and TPP if available.

Responses

Response body

object

consentStatus

string

required

This is the overall lifecycle status of the consent.
Valid values are:

'received': The consent data have been received and are technically correct.
The data is not authorised yet.
'rejected': The consent data have been rejected e.g. since no successful authorisation has taken place.
'valid': The consent is accepted and valid for GET account data calls and others as specified in the consent object.
'revokedByPsu': The consent has been revoked by the PSU towards the ASPSP.
'expired': The consent expired.
'terminatedByTpp': The corresponding TPP has terminated the consent by applying the DELETE method to the consent resource.

received rejected valid revokedByPsu expired terminatedByTpp

challengeData

object

Request body for a consents request.

image

string

data

array

data

imageLink

array

imageLink

otpMaxLength

array

otpMaxLength

otpFormat

array

otpFormat

additionalInformation

array

additionalInformation

consentId

uuid

required

ID of the corresponding consent object as returned by an account information consent request.

_links

object

required

A list of hyperlinks to be recognised by the TPP.

Type of links admitted in this response (which might be extended by single ASPSPs as indicated in its XS2A
documentation):

'scaRedirect':
In case of an SCA Redirect Approach, the ASPSP is transmitting the link to which to redirect the
PSU browser.
'scaOAuth':
In case of an OAuth2 based Redirect Approach, the ASPSP is transmitting the link where the configuration
of the OAuth2 Server is defined.
The configuration follows the OAuth 2.0 Authorisation Server Metadata specification.
'startAuthorisation':
In case, where an explicit start of the transaction authorisation is needed,
but no more data needs to be updated (no authentication method to be selected,
no PSU identification nor PSU authentication data to be uploaded).
'startAuthorisationWithPsuIdentification':
The link to the authorisation end-point, where the authorisation sub-resource has to be generated
while uploading the PSU identification data.
'self':
The link to the Establish Account Information Consent resource created by this request.
This link can be used to retrieve the resource data.
'status':
The link to retrieve the status of the account information consent.
'scaStatus': The link to retrieve the scaStatus of the corresponding authorisation sub-resource.
This link is only contained, if an authorisation sub-resource has been already created.

scaRedirect

object

Link to a resource.

scaOAuth

object

Link to a resource.

startAuthorisation

object

Link to a resource.

startAuthorisationWithPsuIdentification

object

Link to a resource.

startAuthorisationWithPsuAuthentication

object

Link to a resource.

startAuthorisationWithEncryptedPsuAuthentication

object

Link to a resource.

startAuthorisationWithAuthenticationMethodSelection

object

Link to a resource.

startAuthorisationWithTransactionAuthorisation

object

Link to a resource.

self

object

Link to a resource.

status

object

Link to a resource.

scaStatus

object

Link to a resource.

psuMessage

string

Text to be displayed to the PSU. Used only during Decoupled Authorisation.

Headers

object

X-Request-ID

uuid

ID of the request, unique to the call, as determined by the initiating party.

ASPSP-SCA-Approach

string

This data element must be contained, if the SCA Approach is already fixed.
Possible values are

DECOUPLED
REDIRECT
The OAuth SCA approach will be subsumed by REDIRECT.

Location

uri

URI where the client can view and accept consent. In case of errron will be returned redirect uri with error and error description

Examples:

success example with Location:

https://customerconsent.tbcbank.ge/loginappsandbox/session?sessionid=219d20e1-a34e-4608-89bc-0d55c66dd576
error example:

https://tempuri.org/callback?error=server_error&error_description=The authorization server encountered an unexpected condition that&state=e09bd498-262d-41be-8744-6a706ab3426a

Language

URL


xxxxxxxxxx
1
curl --request POST \
2
     --url https://test-api.tbcbank.ge/xs2a-sandbox/v2/consents/account-access \
3
     --header 'accept: application/json' \
4
     --header 'content-type: application/json' \
5
     --data '
6
{
7
  "recurringIndicator": true
8
}
9
'

Click Try It! to start a request and see the response here! Or choose an example:

application/json

application/problem+json

201Created

400Bad Request

500Server Error