general

Overview

Salt Edge developed an API platform - Open Banking Gateway that allows financial institutions to get instant access to customers’ bank accounts in Europe and beyond for account information and payment initiation purposes, via a single API.

Open Banking Gateway includes the following components:

  • Account Information API enables authorized TPPs to access all PSD2 AISP channels, available in the EU and beyond, via one API, to aggregate their customers’ account data.
  • Payment Initiation API helps authorized third parties (including banks) to securely initiate payments via PISP channels.
  • Data Enrichment Platform transforms raw transaction data into actionable insights:
    • Transaction Categorization API for assigning a category to personal and business transactions.
    • Merchant Identification API for determining the exact place where the transaction took place and providing detailed info on the identified merchant.
    • Financial Insights - a report generated based on bank data using complex algorithms, provides institutions with financial behaviour profiles of their potential customers.
  • Partner Program API allows institutions to securely connect to PSD2 channels in the EU, without having their own licence and eIDAS certificate.

Data types

All of the responses returned by Open Banking Gateway are in the JSON format. The description of the data types encoded in a JSON response is below.

boolean

A boolean value true or false

date

A date in the YYYY-MM-DD format

datetime

A date in the ISO-8601 format

float

A value corresponding to a real number using the double-precision representation

integer

A value corresponding to a 64-bit unsigned integer number

object

A string representing a JSON object (please refer to the RFC 4627 for more information)

string

A UTF-8 compatible sequence of characters

boolean

A boolean value true or false

date

A date in the YYYY-MM-DD format

datetime

A date in the ISO-8601 format

float

A value corresponding to a real number using the double-precision representation

integer

A value corresponding to a 64-bit unsigned integer number

object

A string representing a JSON object (please refer to the RFC 4627 for more information)

string

A UTF-8 compatible sequence of characters

Security

Encryption

All sensitive data is encrypted using 2048-bit keys, which allows us to set a secure environment for the client. None of the sent credentials are saved within the system as plain text, and are always encrypted using an asymmetric encryption algorithm. If there is something wrong with the client’s data, WrongRequestFormat error will be returned.

We are continuously monitoring Salt Edge API, securing it from malware attacks, and constantly updating the security layers of our infrastructure. Salt Edge offers you a stable and attack-proof environment where you can keep all your credentials intact, and hidden from a potential attacker.

Certificate

We recommend you to check the Salt Edge SSL certificate fingerprint on every connection.

HTTP Public Key Pinning (HPKP)

Salt Edge returns a Public-Key-Pins header in all of its responses. Modern browsers like Chrome and Firefox already use it to validate the public key of Salt Edge certificate. Additionally, you can use this header to validate the certificate on your backends during API consumption. For more information see https://developer.mozilla.org/en-US/docs/Web/HTTP/PublicKeyPinning.

Bug Bounty Program

Salt Edge truly believes that collaborating closely with experienced security researchers from across the globe is an essential part of identifying and mitigating security vulnerabilities in Salt Edge infrastructure. Therefore, Salt Edge is happy to reward the researchers that have identified original and previously unreported vulnerabilities.

If you believe to have found a security vulnerability, we encourage you to visit our Bug Bounty Program.

Signature

For live clients absolutely all requests should be signed. For the clients with other statuses, it is optional:

  • If the signature headers aren’t sent, the request will be performed without any signature validations;
  • If the signature headers are sent, the request signature will be verified.

Before all, the clients who use API key of type service should provide their public key by inserting its content in the keys.

The private key should be securely stored on your server.

In case of possible security breach, the private key should be regenerated and the public key should be updated in your profile.

Signature headers

For a better understanding of how to adapt the corresponding headers in your application, take a look at the sample applications for platforms such as:

The following headers are required for your request to be considered signed:

  • Expires-at - request expiration time as a UNIX timestamp in UTC timezone. We suggest to use +1 minute from the current time. The maximum value is 1 hour from now in UTC, otherwise ExpiresAtInvalid error will be raised;
  • Signature - base64 encoded SHA256 signature of the string represented in the form Expires-at|request_method|original_url|post_body|sha256_of_uploaded_file| - 5 parameters concatenated with a vertical bar |, signed with the client’s private key.

The fields request_method, original_url, post_body and sha256_of_uploaded_file from the Signature header represent:

  • request_method - uppercase method of the HTTP request. Example: GET, POST, PATCH, PUT, DELETE, etc.;
  • original_url - the full requested URL, with all its complementary parameters;
  • post_body - the request post body. Should be left empty if it is a GET request, or the body is empty;
  • sha256_of_uploaded_file - the uploaded file digested through SHA256 algorithm. Should be left empty if it is a GET request, or no file uploaded.

An example of the string that is to be used to generate the signature looks as follows:

  • GET string example: 1413802718|GET|https://www.saltedge.com/api/v5/providers?from_id=123|;
  • POST string example (without file): 1413802718|POST|https://www.saltedge.com/api/v5/customers/|{"data":{"identifier":"my_unique_identifier"}};
  • POST string example (with file): 1413802718|POST|https://www.saltedge.com/api/v5/customers/|{"data":{"identifier":"my_unique_identifier"}}|6979a174280bdf7319940c59fabbd2b8|.

RSA keys generation instruction

1) Install openssl package

Mac OS X

Install via Homebrew: brew install openssl

Ubuntu Linux

Apt-get install openssl

Mac OS X

Install via Homebrew: brew install openssl

Ubuntu Linux

Apt-get install openssl

2) Create the RSA Key Pair

For Mac OS X and Ubuntu Linux:

  • Type in the command line:

    openssl genrsa -out private.pem 2048
    openssl rsa -pubout -in private.pem -out public.pem
    

For Windows:

  • After the package has been installed, a folder with name: OpenSSL-Win32 should appear at the install path.

  • Next, open a Command Prompt and change your current directory to this folder by typing:

    cd C:\OpenSSL-Win32\bin, where C:\OpenSSL-Win32 should be replaced with the install path.

  • Then you can generate RSA keys by typing:

    openssl genrsa -out private.pem 2048
    openssl rsa -pubout -in private.pem -out public.pem
    

then follow the instructions that appear afterwards.

The pseudocode to generate the signature

base64(sha256_signature(private_key, "Expires-at|request_method|original_url|post_body|sha256_of_uploaded_file|"))

Headers example:

Expires-at: 1413466421
Signature: 0o6LgMnlG7FX5tWLoKd6V5jlktodP8I/3vWqh1pOZvPgMn/WPq5YqZWPc0teey135RO2muFThcvuZJtcbaUje1UWFHyWhTh89guHJ47pgBB7w0LMkRw3XskEsafEUZketeTY/NtyeU7ETHHm2Tlw8IJho+gk51Rtp7JJPanw2OZG/6BElFcL0qGs4ohTmJUKKsdI1eo5jseFqF+sX0T4dRYqL7ebhDCD8YsYdsZ9zxlX88+YtUQnEqGbswOH4saGaQNH9NjxST2NS8MFtCU7uwZGybBk4i0l1wtbTJwfgaa+yb2L7l0ltIgxZFJzQOShpVOgI+o8fUg31lOblmMVkpyvXJ/n5Ed2u0nA1yMWkQUPpu03Xkh2RG7qbBOEq6+A374OnhUDwi5TUqYrY89paPwq/A7z2lc56Q84T+NrSLdi0x0aejpp6Cn90Yqpbs04dIio579+KyLm/8XoZ4p9k7vz6vTpDITyTAc93/KHnqeT1hTp7AWMaxuGfEI361fyZLDzkSvnHq4QzMkJOKhPELxSji99dm0LCSZpUiUhTTU3G09LvLBCEFLvbGJzxlO7NgqOGVPMlEc4fJqzU/jrTfkodn4DtzaOJghlXynithKIUBAkpNY9QGPOQIMvcbOZfhilm+bjWuYeNpeALvbqY3ONcibHLjc8ItAVMzORSFg=

Authentication

For more information about the Expires-at and Signature headers, see Signature page of the guides.

All of the resources queried through the API are protected by 4 different headers, on different levels of security, as shown on the diagram below:

Headers diagramm v5

App ID and Secret

The App-id and Secret headers should be passed in with every request. Keep in mind that you can obtain these keys on your API keys page.

Here’s an example request listing all the countries that the API currently supports.

Services and Apps authentication

There are 2 types of access to Open Banking Gateway - as a service or as an app. The type of access is set up by the type of the API key that you are using while accessing the API:

  • service - intended to be used by backends, all the API endpoints are available

  • app - intended to be used by Applications without a backend. Some endpoints for this type of Secret are not available, because mobile applications can be easily compromised/reverse engineered, hence the are security constraints in place to mitigate this

Customer secret

In order to create connect_sessions, connections and oauth providers, your app should pass the Customer-secret header inside the request, so the API can identify which customer the entity belongs to.

Connection secret

Since an app should be able to query information only about the connections it created, requests that query or modify connections should be signed with a Connection-secret header.

URL

https://www.saltedge.com/api/v5/transactions?account_id={account.id}

https://www.saltedge.com/api/v5/transactions?account_id={account.id}

Method

GET

Authentication

Sample Request

curl -v -H "Accept: application/json" \
        -H "Content-type: application/json" \
        -H "App-id: $APP_ID" \
        -H "Secret: $SECRET" \
        -X GET \
        https://www.saltedge.com/api/v5/transactions?account_id=100
curl -v -H "Accept: application/json" \
        -H "Content-type: application/json" \
        -H "App-id: $APP_ID" \
        -H "Secret: $SECRET" \
        -H "Customer-secret: $CUSTOMER_SECRET" \
        -H "Connection-secret: $CONNECTION_SECRET" \
        -X GET \
        https://www.saltedge.com/api/v5/transactions?account_id=100

Rate limits

Open Banking Gateway uses an array of safeguards against bursts of incoming traffic to help maximize its stability. Applications which send many requests in quick succession may see error responses that show up as status code 429.

Response payload

{
  "error": {
    "class": "RateLimitExceeded",
    "message": "Rate limit of 5 requests/s per IP was exceeded for this endpoint."
  },
  "request": {}
}

Versioning

Any incompatible changes to the API will result in incremented versions of the API, which will change the resource URLs.

At some point, the current version will be announced as Deprecated and you will have 12 months to switch your applications to a newer version of the API. All clients will be notified of any deprecation in the API.

New fields can be added to the current API version, at any time without preliminary warning with subsequent documentation added afterward. However, already documented fields cannot be modified or removed. Please rely solely on them.

Client Dashboard

As a client, it is possible to let others access your Open Banking Gateway application. For this, you have to create users, so they, in their turn, can access the information provided by the interface.

If the same email address is used for registering to different applications (Account Information API, Partner Program), then all the applications will be accessed from the same interface by switching between the applications:

Client dashboard switch apps

In the creation form, you will see a field, describing user’s roles. The roles and their meanings are as follows:

Client user roles:

  • Custom - Has custom roles assigned;
  • Finance - Best for accounting people, who can access and handle billing information and payments;
  • Support - Best for employees who regularly respond to end-customers queries related to bank connections;
  • Developer - Best for developers or people using Salt Edge API first hand;
  • Administrator - Best for business owners and company administrators;
  • Owner - Has all the available roles;

Action Roles:

  • Manage customers - delete a customer;
  • Access payments - see the list of Payments in the Dashboard;
  • Manage payments - manage Payments;
  • Access connections(logins) - see the connections(logins) list;
  • Manage connections(logins) - refresh/reconnect/delete a connection(login);
  • Access accounts - see accounts list and details;
  • Access transactions - see transactions list and details;
  • Access Application/Company info - see client profile data, address;
  • Manage Application/Company info - update client profile data, address;
  • Access Keys & Secrets - see the Keys & Secrets of the application;
  • Manage Keys & Secrets - create, update and delete the Keys & Secrets ;
  • Access callbacks - see client’s callback URLs;
  • Manage callbacks - update client’s callback URLs;
  • Access invoices - see invoices list;
  • Manage invoices - pay an invoice;
  • Access eIDAS Certificates - see eIDAS Certificates;
  • Manage eIDAS Certificates - create, update and delete eIDAS Certificates;
  • Access teammates - see the team behind your client;
  • Manage teammates - add, edit and delete teammates;
  • Access Company Tickets - see and reply to the tickets from Help Desk;
  • Manage Company Tickets - see, create and update and tickets from Help Desk;
  • Access Customer Reports - see the generated Customer Reports;
  • Manage Customer Reports - generate, download and delete Customer Report;
  • Access Availability (providers) Stats - view Availability Stats (Global Stats and Application’s Stats);
  • Manage Activity Report - download Activity Report for the range of 1 year or up to 1000 records.;

When a client is created, only the account holder can cancel client profile and destroy data.

Client Provider Keys

Open Banking Gateway now supports Account Information and Payment Initiation Services channels, which can be used with PSD2 and Open Banking compliant APIs. The connection to such a provider is possible only if you create a Provider Key (set of credentials) for it. In this case, the API keys for Providers are provided and controlled by you. The number of keys is restricted to 1 per provider. After you create the key, the provider will be accessible as an usual provider.

Salt Edge now supports eIDAS Certificates. Learn more.

Integration

To integrate your App’s individual keys with a Financial Provider (ASPSP in PSD2 terms), follow these steps:

  • Visit Provider Keys page of your Client Dashboard, select a provider you want add your client keys for, read the instructions and complete the form. You can see all the available providers by going to the New tab on the same page;

  • Proceed by visiting the Connect page and search the provider you just created the key for. It will have a small subscript below the provider name stating that this provider is accessed via YOUR_CLIENT_NAME;

  • The rest of the process is exactly the same as with usual providers.

API Connect - Salt Edge Connect

In case of using API Connect instead of Salt Edge Connect, it should be ensured that the code handles the new provider’s field nature - dynamic_select, with its options dynamically generated and sent in an Interactive callback.

Testing

For the purpose of testing individual keys Salt Edge has developed the following list of Fake providers:

  • fake_client_xf - requires a username and password (embedded);

Sample key:

client_id: "fake_client_id",
client_secret: "fake_client_secret"
  • fake_oauth_client_xf - asks for authorization (OAuth redirect);

Sample key:

client_id: "fake_client_id",
client_secret: "fake_client_secret"
  • fake_interactive_client_xf - asks for a fake SMS code in addition to username and password (embedded).

Sample key:

client_id: "fake_client_id",
client_secret: "fake_client_secret"

To see these providers in API or Salt Edge Connect, don’t forget to set include_fake_providers parameter as true on connection(login) create/reconnect or connect session create/reconnect.
All of the providers that are supported in this mode have _client_ in their provider code.
In case your Provider isn’t supported by our Open Banking Gateway, please fill this form and we’ll integrate it in due time.


eIDAS Certificates

Open Banking Gateway supports only soft issued eIDAS certificates and Open Banking UK certificates.

For the purpose of identification, ASPSPs(Account Servicing Payment Service Providers) and TPPs(Third Party Providers) shall rely on using eIDAS (electronic Identification, Authentication and trust Services) Certificates for electronic seal and/or for website authentication. Identifying themselves is mandatory for all TPPs that wish to get access to ASPSP’s sandbox, live API, and/or to non-dedicated channel.

eIDAS Certificates are provided by Qualified Trust Service Providers (QTSPs) who are responsible for assuring the electronic identification of signatories and services by using strong mechanisms for authentication, digital certificates, and electronic signatures.

There are two types of eIDAS Certificates:

  • Qualified Website Authentication Certificates (QWAC) - identification at the transport layer. QWAC is similar to SSL/TLS with Extended Validation used in Internet for the same purpose. It is used for website authentication, so that ASPSPs and Third Party Providers (TPPs) can be certain of each other’s identity, securing the transport layer. TPP should present its QWAC client certificate towards an ASPSP. The ASPSP can choose between using the ASPSP QWAC server certificate or just an existing SSL/TLS certificate to receive the TPP’s identification request.

  • Qualified Certificate for Electronic Seals (QSEAL) - identification at the application layer. It is used for identity verification, so that transaction information is protected from potential attacks during or after a communication. This means that the person receiving digitally signed data can be sure who signed the data and that it hasn’t been changed.

To create an eIDAS certificate in the Salt Edge system, you should accomplish the following steps:

  1. Go to the Client Dashboard.

  2. Go to Settings > eIDAS Certificates

  3. Choose the certificate type you want to create (QWAC or QSEAL) and press Generate CSR.

  4. Go to Settings > eIDAS Certificates and press edit on previously created record.

  5. Send the CSR to the QTSP (you can get test certificate, or buy production certificate)

  6. Get a signed certificate from the QTSP

  7. Go to Settings > eIDAS Certificates and press edit on previously created record.

  8. Insert the received certificate in PEM format into the form and press update.

  9. Choose a certificate that you want to use for identification, press edit and mark it as active.

Dynamic Registration

Dynamic Registration is a feature that allows you to easily register to any Open Banking API that supports this feature.

Under the hood it makes a request as specified in the bank’s API documentation using the eIDAS Certificates and Keys generated in Client Dashboard.

Additionally Dynamic Registration can be used to add multiple providers that are related to an API hub or Bank Group (ex: Sparkassen-Finanzgruppe, Unicredit Group, etc.)

To create a Dynamic Registration attempt, you should accomplish the following steps:

  1. Sign in to Client Dashboard.

  2. Go to Settings > Dynamic registration

  3. Сlick on Create Key and input the desired search for the desired Dynamic Registration and complete the form.

  4. After finishing the creation step you will get a message with the status of Dynamic Registration.

  5. On your Provider Keys page all the providers related to that Dynamic Registration will now appear. You will also notice that they’re categorized as Dynamic registration type.

Your Account

While using Open Banking Gateway, your application can have one of the several statuses, each with its limitations.

Pending

Upon registration, your application will have Pending status. You can only access the fake providers (Account Information | Payment Initiation), and use up to 10 fake connections(logins). When you perform an action that is not permitted for pending clients, we respond with a ClientPending error.

When your app is not in Live status, you can also destroy data, which lets you destroy all the customers with their corresponding connections(logins), accounts and transactions.

In order to upgrade the status from Pending, you have to:

We will examine your application and upgrade it to the Test status in two business days.

Test

In order to retrieve live bank account data and initiate payments through Open Banking Gateway, please access the request test access page and fill in all the requirements. When done, press the “Request Test Access” button.

In the Test status, your app can already use live providers, but it’s still limited to 100 connections(logins). Also, the clients that have eIDAS certificates with PISP role can test live providers.

In the Test status, your app can already use real providers, but it’s still limited to 100 connections(logins).

When you are ready to transfer to a limitless usage, use the instructions from the Live section below. Note that all of the data will be preserved, but you can also destroy it if you wish to start with a clean slate.

In order to become Live, the client application should use HTTPS for all API callbacks.

Live

a. In case you have any feedback, please contact us via Help Desk

b. We will need to evaluate the integration of Open Banking Gateway on your side for all the platforms the Salt Edge service will be available on (e.g. web, Android, iOS, etc.). We suggest referring to the Before going Live guide and the Development Requirements and Guidelines. We recommend submitting the implementation for review at least 7 days before the planned production release date.

c. When you are compliant from both legal and technical perspectives you’ll be able to request the Live Access.

d. Review and add any missing teammates (e.g. finance team for invoicing purposes, support team to access the dashboard, etc.).

The Live status allows the application to use Open Banking Gateway without any restrictions.

In Live status, you will not be able to see all of your accounts’ and transactions’ details in your dashboard.

Restricted

Your application will have the Restricted status if the payment hasn’t been received. While in this status, your application is in a read-only state, hence it cannot create or reconnect connections(logins), refresh them, or create new connect_sessions.

Disabled

In case of any non-compliance with Terms of Service or Before going LIVE guide, we will contact you to solve the issues. When several attempts to contact the client fail or if any of the non-compliances are not fixed within two days time, the application will be transferred to the Disabled status. In this status, all API requests will return a ClientDisabled error.

Data Volume Limits

Account Information API

Account Information API has been developed to provide real time access to End Users’ financial or other data available from the End User’s Financial Institution. Access to the Account Information API is subject to the following data fetching limits:

  • up to two (2) fetches of new data from any Financial Institution per second (7,200 per hour);
  • limited to one (1) fetch of new data from any Financial Institution per day per End User;
  • if there is a failure to fetch or retrieve new data from a Financial Institution, Client is allowed to make up to two (2) additional attempts to retry fetching new data for the associated End User per day. Retried fetches are subject to the same limitations on fetching calls per second set forth in the first paragraph;
  • Salt Edge gives Client the option to enable automatic fetching of new data per each End User’s connection to a Financial Institution. Salt Edge’s standard automatic fetching time starts at 2AM and ends at 6AM in local time of the capital of the country where the Financial Institution is located. In certain cases, the automatic fetching time is from 2AM to 6AM UTC.

Payment Initiation API

Payment Initiation API has been developed to provide the end-customers the possibility to pay from the account of their choice, using their familiar banking authentication methods. Access to the Payment Initiation API is subject to the following data fetching limit:

  • up to two (2) attempts to initiate a Payment Transaction with respect to any Payment Account held by any ASPSP per second (7,200 per hour).

Data Enrichment API

This Section applies to Client if Client is using the Transaction Categorization API separately. The Transaction Categorization API has been developed to provide real time categorization of Transaction Data. Accessing the Transaction Categorization API is subject to the following limits:

  • categorization request to the Transaction Categorization API must not exceed one hundred (100) Objects;
  • up to two (2) requests of categorization of Transaction Data per second (7,200 per hour).

To learn more about Terms of Service using Account Information API, go here.

Guide for Clients Support

on how to handle issues of API integration

Nature of errors

Error class: Invalid Credentials

Upon receiving any of the error messages from below of “Invalid Credentials” error class, the user has to double-check his credentials within his Online Banking:

  • Invalid Access Number.
  • Invalid Access Number or password.
  • Invalid account number.
  • Invalid agency number.
  • Invalid account, agency or password.
  • Invalid account or agency.
  • Invalid authentication code.
  • Invalid Banking ID and/or password.
  • Invalid captcha.
  • Invalid Card Number.
  • Invalid Card Number or Password.
  • Invalid contact option.
  • Invalid contract number.
  • Invalid contract number or password.
  • Invalid CPF.
  • Invalid Customer Number.
  • Invalid Customer Number or Password.
  • Invalid Date.
  • Invalid date format.
  • Invalid email.
  • Invalid credentials format.
  • Invalid ID-card entered.
  • Invalid identification code.
  • Invalid ID or PIN.
  • Invalid login.
  • Invalid login option.
  • Invalid login or keyword.
  • Invalid login or OTP.
  • Invalid login or password.
  • Invalid login, password or token.
  • Invalid member number or password.
  • Invalid membership number.
  • Invalid memorable info.
  • Invalid memorable info or password.
  • Invalid OTP.
  • Invalid password.
  • Invalid password or answer to secret question.
  • Invalid password or registration number.
  • Invalid password or sms.
  • Invalid personal code.
  • Invalid phone number.
  • Invalid phone number or password.
  • Invalid PIN.
  • Invalid PIN or PASSWORD.
  • Invalid PIN or TOKEN.
  • Invalid REGISTRATION NUMBER.
  • Invalid security code.
  • Invalid security code or password.
  • Invalid security image.
  • Invalid sms.
  • Invalid token.
  • Invalid user code.
  • User code or PIN not correct.
  • Invalid user id.
  • Invalid user id or password.
  • Invalid user id or pin.
  • Invalid username.
  • Invalid username or password.
  • Invalid username or pin.
  • Invalid User-Number.
  • Invalid User-Number or Password.
  • Wrong answer to secret question.
  • Wrong answer to secret question or invalid token.
  • Wrong answers to secret questions.
  • "%{field} must contain no more than %{number} characters."
  • "%{field} must contain at least %{number} characters."

Instructions for specific error messages of “Invalid credentials” error class:

Provider asked to perform an action. Please, log in to your web client.

Note: The user must sign in to his Online Banking and check whether he is asked to: update his personal data (e-mail, phone number, etc.), give his consent (Read and Agree to the Terms and Conditions), close a notification (going paper-free), etc.,

Access declined. Please contact your bank’s customer service.

Note: In some cases, the provider blocks the user’s access due to suspicious activity. In this case, the user should contact the provider’s representatives and inform them of the following issue.

Provider asked to activate your Online Banking client. Please, log in to your web client.

Note: Users usually do not activate the online banking before establishing a new connection from a TPP. Upon this error, please make sure the user has activated his online banking first.

The user is blocked. Please contact your bank’s customer service.

Note: The user must contact the provider’s representatives for assistance.

You cannot access the application.

Note: The user should confirm the interactivity, usually from another app (banking app).

Consent has expired.

Note: The user must perform a reconnect and give his consent again.

Provider does not recognize your credentials.

Note: The user must check his credentials within online banking.

“%{field} must contain exactly %{number} characters.”

Note: The user must either check his credentials again or change them according to the message (right length and characters).

Invalid login or account blocked.

Note The user must check his credentials again or contact the provider’s representatives as his account has been blocked to be accessed on other devices.

Provider asked to update your contact data.

Note: The user must access his online banking and update his personal data (phone number, email, address).

The password is blocked.

Note: The user must change his password within the bank’s interface as it is an action requested by the provider.

PIN too short.

Note: PIN must either be checked or updated.

Password too short.

Note: The password must be updated.

Login too short.

Note: The login must be updated.

Provider asked to change password.

Note: The password must be updated.

Memorable word login option not activated.

Note: The user must activate the following option within the provider’s interface (specific for GB providers).

“%{field} should contain only numbers.”

Note: The user either must check or change the following field according to the message.

Invalid credentials for OFX providers

The providers which have OFX in their code, are integrated via a new interface Quicken Direct Connect (OFX). In order to connect the account, the user should activate Quicken Direct Connect for the Online Banking (additional fees may be applied) and receive a new pair of credentials, which should be used while authenticating. If all the above works, the user should connect once again from the app using the same credentials.

Error during the Interactive authentication

Invalid Interactive Credentials

Note: The user has failed while performing the interactive authentication, i.e. has not confirmed the access from the mobile application, has entered the wrong One-time password, SMS, Token, etc. He/she should retry refreshing and performing the interactive authentication as expected.

Interactive Adapter Timeout

Note1: The user has failed to perform the interactive authentication in time, i.e. has exceeded the time to confirm the access from the mobile application, has not entered the One-time password, SMS, Token, etc. within the requested timeframe. He/she should retry refreshing and performing the interactive authentication as expected.

Note 2: If the bank has changed any of the interactive options (removed or added any new), then please report this issue to our Customer Care team and we will investigate accordingly.

Wrong option value(s).

Note: the client does not handle the dynamic_select field correctly.

Error class: Provider Unavailable

Upon receiving the “Provider Unavailable” error, the user must:

  • check whether he can access his online banking
  • make sure that the provider is not having maintenance work

Specific error messages:

Account blocked. Please, contact your provider.

Note: The user must contact the provider’s representatives for assistance.

Provider does not have any account records available at this time.

Note: The provider is not able to return any information for the user’s accounts at this very moment.

Provider asked to update your account settings.

Note: The user must update his password, login, interactive step, etc.,

User is already logged in or maybe logged out abnormally.

Note: The user must make sure he either ended the session correctly, or whether he still has a session running.

Provider could not complete access. Please, try again later.

Note: The provider was not available at the moment the user tried to connect due to various reasons.

Internal provider error, try again later.

Note: The provider is not available for various reasons. The user should try again later.

Provider is having some maintenance work. Please, try again later.
No active accounts were found. Please, contact your provider.

Note: The user must check whether their accounts have been activated or available within the interface.

To continue working in the ‘Internet bank’ system, you should pay the bill for the use of the system.

Note: The user must pay the internet banking bill to the provider before he continues accessing his data.

Provider is disabled.

Note: The provider is not available anymore. Therefore, new connections can not be established neither old ones can be accessed.

Session closed, due to another active session. Try again later.

Note: The user has another session running on another device for the following provider. The provider cannot be accessed from two devices simultaneously.

The user session has timed out. Please restart the logon process.

Note: The user must restart his logon process due to inactivity.

Request to provider timed out.

Note: The user took too long to connect to the provider and the session has ended. He must try again.

Too many requests.

Note: The user exceeded the number of requests per day for the following provider. He must refresh/reconnect the next day.

Provider unavailable, try again later.

Note: The user must check whether he can access online banking or whether it is under maintenance.

Error class: Provider Error

Any error message under this class shall be submitted via Client Dashboard Help Desk or at support@saltedge.com.

Error class: Server Error

You have already used these credentials to connect with this provider

The user has already created a connection to the same provider and now he is trying to add the same accounts, authenticating with the same credentials.

The user should either reconnect the existing connection or delete it and create a new one.

How to report issues

General rules

1. Include all the user reports per provider in one ticket (NOT several ones).

Note 1: If the provider’s availability is decreasing and the number of reports from users keeps increasing, keep track of the users list on your end and report only one issue. Such issues are generic and once the fixes are applied, they work the same way for all the users.

Note 2: If there are several different issues for the same provider, eg. ProviderError and Wrong balance, then send two reports, one for each issue.

Note 3: If the same user has connected more providers and encounters issues with more than 1 provider, then send separate reports, one for each provider issue.

2. Send the report in a well-read and fixed structure

Subject line: Provider_name: (Generic nature of the issue)

Issue description: Offer as many details as possible so that the development team started working on the issue in due time. Below, please find the recommended structures of the issue per case.

Specific issues

Duplicated transactions

When the transactions duplicate, please specify as many details as possible. Suggestion of how to structure the report:

  • Connection/Login id
  • Account id to which the duplicates pertain
  • Transaction ids of duplicates / the amounts and dates of the duplicates
Missing account(s)/cards

Suggestion of how to structure the report:

  • Connection/Login id
  • Account/card nature
  • Account/card name
  • Any useful information that will help us detect and fetch the missing account/card (eg. the location within the bank’s interface)
Missing transactions

Suggestion of how to structure the report:

  • Connection/Login id
  • Account/card id to which the missing transactions belong
  • Transactions amounts and made_on dates
  • Any useful information that will help us detect and fetch the missing transactions
Wrong balance amount/sign

Suggestion of how to structure the report:

  • Connection/Login id
  • Account/card id to that has wrong balance/balance sign
  • Specify which amount/sign is the expected one
Wrong transaction made_on date

The user shall make sure the made_on date of the transaction fetched to the financial app coincides with the one from the Online Banking, not Mobile Banking.

Suggestion of how to structure the report:

  • Connection/Login id
  • Account/card id to which such transactions belong
  • Specify which made_on date is the expected one

FAQ

How much time is it expected to fix the interactive providers?

The interactive providers require 2FA authentication for security reasons. Therefore, for interactive (MFA) connections, the Resolution Time may be indefinite as it depends on the end-user’s activity and amount of iterations needed to restore full functionality.

I changed my mobile phone. How do I reset the MFA for my Salt Edge Client Dashboard?

Contact us via Client Dashboard Help Desk or at support@saltedge.com and let us know about this issue. We will reset your MFA and send you the instructions to follow afterwards.

How to change the status of the client (pending/test/live/restricted)?

Two options are advised:

How to handle OAuth providers that support App2App?

This happens when the application opens the connect window in a web view inside the app. When the PSD2 provider finishes authorizing the user, they redirect them back to the redirect_url we pass them. It eventually opens in the user’s browser, which does not share cookies with the web view inside the app. This affects apps that use Salt Edge Connect or the Partners API to connect to OAuth providers that support App2App.

A solution for this case would be to open the Salt Edge session in the web browser as opposed to a web view.

These are some guidelines you can rely on for both iOS and Android:

How often shall I sync all my data with Salt Edge?

Salt Edge regularly updates all the data in the system, that is why we recommend synchronizing your data with the data Salt Edge provides you.

Our data is being updated on the following basis:

  • countries - rarely, maximum once per day;
  • currencies - rarely, maximum once per day;
  • currency rates - everyday, at 12:00 UTC;
  • categories - updated only on a new API version release;
  • providers and provider fields - new providers are added frequently, but the providers or their fields are updated rarely (around 10 changes per month, mostly on bank interface update). We recommend updating the providers and their fields once a day.

What is your pricing policy?

Salt Edge takes a personalized approach to each and every client. To get a quote, please contact our Sales team.

How does connection(login) refresh work?

Automatic data refresh works for every connection(login), except the ones that satisfy any of these conditions:

  • If there was an error introducing your client’s credentials to connection(login) (InvalidCredentials) - in this case the connection(login) will be set as inactive (due to the old credentials being wrong);
  • If less time time than shown in provider.refresh_timeout (usually 1 hour) passed between the updates;
  • If the connection(login) credentials have not been saved (store_credentials flag is set to false);
  • If the provider.mode field is set to file.

Are the connections(logins) automatically refreshed?

Salt Edge regularly updates all the connections(logins) that satisfy the following conditions:

  • Connection’s(login’s) daily_refresh attribute has the true value;
  • The connection’s(login’s) status is set to active;
  • Connection’s(login’s) provider_mode is set to any value except file;
  • The automatic_fetch attribute of the last attempt has the true value;
  • The last stage of the attempt has the name of finish.

If these conditions are met, the connection(login) will be updated according to the time specified in refresh start time in the local time of the country the connection(login) belongs to.

I encountered “ActionNotAllowed” error. What should I do?

By default, all Open Banking Gateway clients can use Salt Edge Connect for quick and easy API integration into their app or service. API Connect allows the clients to perform connection(login) actions directly via the API. Access to these routes requires the client to adhere to high security standards, as it involves handling of sensitive customer information. Access to the API Connect routes is subject to manual review and activation and is granted to the ISO 27001 certified parties, registered AISPs and PISPs, as well as selected companies adhering to leading industry security requirements.

Please contact your Salt Edge account manager or sales representative you are in touch with at sales@saltedge.com for further assistance.

Who owns the financial institutions logos appearing in the Open Banking Gateway?

Salt Edge does not own the marks, brands and/or logos of the various financial institutions (banks, e-wallets, payment system providers) that appear in the Open Banking Gateway. We only display them for Salt Edge clients’ convenience and ease of use. Such marks, brands and/or logos are the property of their respective owners and are used for identification purposes only. Their display in the Open Banking Gateway is not sponsored by the respective owners, and does not imply any product or service endorsement by, or affiliation with, Salt Edge. The use of these marks, brands and logos is at Salt Edge clients’ own risk, who are solely responsible for obtaining any applicable permission or authorization from the respective owners. Salt Edge does not make any representation or warranty, express or implied, with respect to such marks, brands and/or logos and expressly disclaims any responsibility or liability arising therefrom.

Common Issues

Generate token for Fio Banka

Here you will find instructions how to obtain an integration key (token) in Fio Bank’s user environment. This integration lets you read future transactions as well as already posted ones.

During the setup, you can select a date from which the transactions are retrieved.

WARNING : Fio Banka makes available only already recorded transactions, therefore, it takes usually 1-2 days before the transaction appears in the application.

We recommend you to log into online banking using a desktop computer (laptop) - the appearance of the control interface will respond to our instructions and help avoid possible compatibility problems on mobile devices.

  • Log into Online Banking Fio and click on “Settings” in the upper right corner
  • In the settings menu, select the “API” icon
  • Select the account you want to integrate and click on the “Add a new token”
  • Copy the generated token to a text file or clipboard
  • Set the token to “Only monitor the account”, give it a name and specify its validity (after expiration it will be necessary to generate the token again)
  • Click on “Send”.

Privat24 API

Getting Merchant ID and Merchant Password for PrivatBank API.

  • Go to Privat24 and select from the menu Все услуги → Бизнес → Мерчант
  • Select an account to sync
  • Specify the IP address 88.99.26.2
  • Check the boxes «Баланс по счёту мерчанта физлица» and «Выписка по счёту мерчанта физлица»
  • The tab “Мои мерчанты” will contain the Merchant’s Number and password. Copy their input fields to Salt Edge Connect.

More information can be found here.

Generate token for TransferWise

  • Log into your TransferWise account.
  • On the menu on the left click on API tokens.
  • Scroll down and click on API tokens.
  • Click on Add new token.
  • Give your token a name or description and select Read only, click on Create token.
  • To reveal the token click on Reveal Key.