Errors documentation

Errors can be a bit confusing sometimes, despite the fact we spend time to make them as simple as we can. The new OB formats, for returning errors, allows us to provide a URI to give further details. This section of the docs would serve that purpose and provide further context on any errors you may have hit.

OB API errors


The page number you send couldn’t be parsed as a number.

  • OBRI.AccessToken.Invalid

The access token doesn’t have the right scopes to access the resource. If that’s still obscure, see an access token as a door key. Not having the right scope is like not having the right key for opening the door.


The access token in our OBRI environment are JWTs. Therefore, before even validating an access token, we verify first it’s a JWT It sounds like in your case, the access token is not a JWT one. Perhaps you appended extra characters by mistake or you truncated it.


The access token is not valid. The scopes of it looks correct, it’s more that it is bind to a TPP and resources that you are not allowed to access.


The access token is bind with an account request that doesn’t exist. You may have deleted the account request already for example.


The access token is bind to a payment ID that doesn’t match the resource you are accessing. You may have mixed up access token. Double check that the access token is the one you used for this particular payment flow.


Each ASPSPs get a dedicated financial ID. This is used so in case a TPP send the request to the wrong ASPSP by mistake, at least, the wrong ASPSP is able to detect the error message. If you got this error, it means you send the wrong financial ID header and therefore, our ASPSP rejected it.


It sounds like the account request was associated with a different TPP than your transport certificate. You may have mixed up transport certificates or account requests.


It sounds like the access token was associated with a different TPP than your transport certificate. You may have mixed up transport certificates or access token.


The account request status is incorrect. To be fair, it’s a situation most unlikely to happen. This is an additional security layer we implemented. We invite you to contact us so we can help you with that issue.


The account request has been revoked by the PSU from the ASPSP UI.


The account request has expired. In that scenario, start again the consent request flow with the PSU.


The account request can’t be found. You may have deleted the account request already. if you think that’s not the case, please contact us


The account request is associated with a set of accounts, choose by the user. You are apparently trying to access an account that the PSU didn’t consented you to access.


You are trying to ask for a specific set of permissions in your account access consent request but some of the permissions you requested are not supported on this sandbox. Some ASPSPs do bot support all the available account access data types and therefore do not allow a TPP to request permission for something they do not support. To resolve this issue, remove the forbidden permissions (listed in the error message) from your account access consent request body to proceed.


When a PSU consented to share his accounts data, you asked for a specific set of permissions. Like Transactions, balances. It sounds like now, you are trying to access a resource that you didn’t ask the permissions initially. Either you need to ask the PSU to extend his consent for the other permissions, or you may restrict the user experience based on what the PSU authorised you to access. In any case, the ASPSP is respected the PSU consent and is not going to give you access to this resource.


Having the permissions for an endpoint is sometimes not enough. For example, you can’t get the transactions of a PSU if he never authorised you to access either the CREDIT or DEBIT transactions. This error is thrown when you violated one of those rules, which are in the Open Banking standard.



You are trying to submit the same payment twice. Nice try ;)


You have already uploaded a file for this payment consent.


The payment request status is not okay for submitting a payment.


The payment initiation doesn’t match the initial request. When you created the payment, you did send the payment details. When you submit the payment, you also send the payment details again, as security check. Apparently, you did not send the same payment details. Have you change the price just for testing?


The payment risk doesn’t match the initial request. When you created the payment, you did send the payment risk. When you submit the payment, you also send the payment risk again, as security check. Apparently, you did not send the same payment risk.


The payment submission can’t be found. You may have deleted the account submission first by mistake.


Payment ID specified in the request is unknown. You may have used a payment ID from a different ASPSP.

You are trying to submit a payment but the consent for this payment cannot be found. Please check the Consent Id you have provided matches an actual authorised consent.


The 'Exchange Rate Type' you provided in the consent for an international payment is not one of the supported values in this version of the payments API. Please submit a valid rate type, for example: ACTUAL, INDICATIVE, AGREED.


They exchange rate information you provided in the payment consent for this exchange rate type is not valid. Please check the payment specifications. For example, some Exchange Rate Types do not support a specified exchange rate or a contract identifier in the consent.


You are trying to submit the same payment submission twice.

Funds confirmation


You have submitted a funds confirmation request for a PSU but they have not authorised the consent for this action yet. Please wait until the PSU has authorised the funds confirmation consent.


You have submitted a funds confirmation request for a PSU but the consent has been rejected. This may be because it has been revoked or because the authorisation failed.


You have submitted a funds confirmation request for a PSU but the consent has expired. Please check the 'Expiration Date Time' on the Funds Confirmation consent.

TPP registration


Your TPP is already registered to this ASPSP. You don’t need to register again. If you loose your client ID for a reason, you can always use the GET method to retrieve it.


We don’t recognise your transport certificate. The CA that issued this certificate is not supported by us. More likely you have used the wrong one, verify it comes from the right directory.


The SSA you presented is bind with another TPP than your transport certificate. What this mean is that you either using the SSA from a different TPP or your transport certificate is not the right one.


The registration request JWT is invalid for some reason.


We verify the registration request, and in particular if it is consistent with the SSA you provided. Some of those rules can seems a bit over complicated, keep in mind that Open Banking is re-using the OAuth2 dynamic registration and for those reason, it may complicated things.


The registration request you send is not a JWT. The first things we do before validating it is parsing it and verifying the signature. Apparently, we haven’t reach the first step of parsing it correctly.


Your TPP is not registered yet with this ASPSP. The process is to get a software statement registered in a directory, like the ForgeRock directory, and then to on-boarding with all the banks you want to use. In this particular, what you need to do is to on-boarding with our ASPSP.


We failed to register your OIDC client. This usually mean a violation of the OIDC standard. Make sure your request is compliant of the OIDC dynamic client registration and OAuth2 dynamic client registration.


The SSA you have attached to your registration request JWT is not valid. It could be for example expired or signed by a non-trusted directory.


The SSA should be a JWT format.

File payment


You have uploaded a file for a file payment consent but the file has an incorrect hash value so may be corrupted or modified. The SHA256 hash of the file you upload must match the hash provided on the file payment consent.


You have uploaded a file for a file payment consent but the file does not have the expected number of transactions present in it. The number of transactions in the uploaded file must match the number specified in the file payment consent.


You have uploaded a file for a file payment consent but the file does not have the expected control sum value. The total value of the transactions (ignoring currency) in the uploaded file must match the control sum value specified in the file payment consent.


You have uploaded an empty file.


The have specified a 'File Type' with an XML format but the XML file provided is not valid. Please check the file content matches the specified File Type.


The have specified a 'File Type' with an XJSONML format but the JSON file provided is not valid. Please check the file content matches the specified File Type.


You have requested a file payment report file but the file payment is not yet authorised and accepted. A report can only be generated for a file payemnt that has been authorised by the PSU and has had a File Payment Submission created for it (i.e. Accepted in Progress or Accepted Settled).

Generic REST errors

The REST layer of our application has some sanity check. All the errors above are generic REST errors, meaning you request haven’t reached our Open Banking layer underneath.


One of the field is not valid. Verify with the swagger API the format expected


The object received in the body generally, is not in the expected format.


The request parameter JWT is invalid. The error should give you more details on the reason behind.


The request parameter format should be a JWT (JWE or JWS). Please verify the format of your request parameter.


Some claims are mandatory (see OB standard and OIDC standard). The error details should give you the claim we expect to be mandatory.


Query parameters are not signed but JWT claims are. The standard OB and OIDC are requesting that some claims to be repeated in the query parameter. For security reason, those values should match, otherwise you get this error.


One of the mandatory request parameter is missing.


The request binding failed, which is the operation of matching your request with the according endpoint. This is usually link to the path variables not been correct for example.


The type of one of the argument is not valid. Verify with the swagger API you are sending the right type of object.


The request method is not the one expected.


The request media type is not the one expected.


The request media type is not acceptable from our server backend.

HTTP also has the dedicated “Accept” header – which is used to specify media types the client recognizes and can accept. Simply put, the server will send back a resource representation using one of the media types the client requested. However, if there is no common type that both sides can work with, our server will throw this error.


The body is not in a readable format, which usually mean your json object is malformed.


One of the request path is missing. Verify with the swagger of the endpoint you want to use, which path variable you must defined.


The request is missing a mandatory header.

The request is expecting to receive a cookie, which apparently is missing.


One of the mandatory argument is missing.


The header from the request is invalid. Please verify the format.


The list of errors can be quite long and we don’t pretend catching them all nicely. If you hit that error, please contact us and we will add it to the list of known errors.


Something bad happened in our side. Most of the time, it’s due to a new kind of errors that we don’t handle properly. Unfortunately, instead of returning a proper error, you got this 500. Contact us with the details of your request and we will try to sort out this 500 for the future users hitting the same problem.

Data endpoints error


The financial DATA you send is not in the expected format. We adopted the Open Banking standard format. You can use the export endpoint to get a template of what’s format we expect. If you still think it’s not working but the format is valid. Please contact us and we will investigate the issue.

ForgeRock internal errors

We used the same OB format of errors for our internal system. Therefore the list above is more for internal purposes. We are not expected you would received one of those error using our ASPSP.

ForgeRock TPP: ID Token errors


The format of the ID token is invalid. This error is designed for our sample TPP.

ForgeRock RCS

The RCS consent request format is invalid. We expect to received a JWT

The RCS consent JWT is invalid. The signature or the consent of it is not valid.

The RCS consent response failed. We couldn’t generate the JWT response

The account request behind the RCS consent request doesn’t exist.

The RCS consent request does not match the account or payment consent. This usually means that the RCS request and Consent were created with different TPP client IDs or that the TPP in the RCS request was not found.

The TPP specified a debtor account in the payment consent but it is not one the the PSU’s accounts. Please check t