Swedbank Open Banking is our invitation to developers and companies to innovate and build applications together, creating the next generation of digital services for millions of Swedbank customers through APIs.

API stands for application programming interface and is a technology used for sharing information between online services and applications.

Open Banking allows customers to use services built by other companies and give permission to those services to access the customer’s bank data, if the customer has agreed to share it. Services built on the Swedbank Open Banking APIs will never get access to a customer's data without the customer specifically giving his/her consent to that application.

Customer safety is our first priority. Open Banking is built on EU PSD2 regulation guidelines and puts customer rights and security in focus. No customer data can be accessed by third parties without proper licensing and first receiving customer consent.

Extending the Mobile BankID adds an additional layer of security for the customer. Some functionality for the customer (both in Swedbank's own channels and in the API) requires an extended Mobile BankID. To extend the Mobile BankID, a code card or PIN calculator is required to verify that the customer is who he or she claims to be as an extra precaution before the BankID is extended. If the customer doesn’t have the code card, he or she needs to request it and it will be sent out by regular post. Extending the Mobile BankID is only required once per device and customer.

The Open Banking Sandbox functionality is a free service. You sign up by using your e-mail address.

The PSD2 APIs (Account Information and Payment Initiation API) are free for licensed third parties. To get access, you also need the required certificates. Read more about how to get access on our PSD2 onboarding page.

Currently we have launched a BETA Sandbox environment and PSD2 APIs (Account Information and Payment Initiation API). To receive news and updates on latest releases, sign up for the Developer Portal and you will be automatically added to our e-mail updates.

In order to use PSD2 APIs, you need to obtain the appropriate PISP and/or AISP licence from your local FSA in the EU or EEE, and passport licence to other countries if you want to use PSD2 APIs in other countries than the country where you obtained the licence.

To use our Premium APIs (still in development), you don’t need a licence. In this case, you need to contact us to agree on a business model and sign an agreement.

To reach our support team for questions about the Sandbox, Developer Portal or production environment, please fill out this form. If you already have an application running, please add Client-ID and App-ID. For very specific issues with requests, also add x request-id and request-uri as it will help us lookup details. 

Our Service Level Agreement (SLA) states that we respond to every inquiry within seven working days, but more than 80% of questions are answered within one day.

Yes, our subsidiary Swedbank Pay has a developer portal with information and documentation about their APIs (for example Payments, Checkout and Gift Cards). You can visit it here.

PISP stands for Payment Initiation Service Providers. These service providers are authorised to initiate a payment on behalf of the customer if the customer has granted such permission.

AISP stands for Account Information Service Providers. These service providers are authorised to view the customer’s payment account information, if such permission has been granted by the customer.

TPP stands for Third-Party Payment Service Providers. It describes both AISP and PISP companies mentioned above.

RTS stands for Regulatory Technical Standard. Market players need to meet specific requirements to comply with the obligations in PSD2. The security measures outlined in the RTS stem from two key objectives of PSD2: ensuring consumer protection, and enhancing competition and a level playing field in a rapidly changing market environment.

Consent is an integral part of PSD2 and collaboration with third parties. The only way that Third-Party Payment Service Providers can act on the customer’s behalf is if the customer has given them explicit consent (authorisation) to have such permissions. The customer also has an overview of who has been granted consent. Consent is valid for up to 90 days but can be revoked at any time by the customer.

OAuth 2.0 is the security model used. It is an open protocol to allow secure authorisation in a simple and standard method from web, mobile and desktop applications. It enables third-party applications to obtain limited access to a web service.

Financial Supervisory Authority. Name of institution varies from country to country, and it is usually the Finance Inspection or Central Bank of the country.

Strong Customer Authentification

If a corporate user gets an error message about lacking permissions to use an Open Banking service, he or she should contact their corporate admin user and ask for the required permissions.

As a previous customer, you can still get the option to log on to Swedbank or a Savings Bank and read documents from the bank and exchange information about your customer relationship. Third-party providers who have integrated Swedbank through screen-scraping, reverse engineering of our own APIs or other methods might have issues with old customer engagements since they are visible through this portal and are enabled as a choice in our profile selector.

Please note that the PSD2 API (or the fallback contingency mechanism in Sweden) is the only channel provided for third parties to access customer data in accordance with the requirements in the PSD2 directive. Old customer engagements are not visible in those channels.

Log in to the Developer Portal to access the developer documentation.

You can also access it here as pdf.

The Developer Portal for Swedbank Norway is available here, and you can find the Open Banking page in Norwegian here.

We will update with the Finnish portal as soon as it is available.

You can register your account here.

Developers and API publishers need one of the following browsers to use the Developer Portal:

• Mozilla Firefox 50 or later
• Google Chrome 55 or later
• Microsoft Internet Explorer 11 or later

Currently, there are two APIs available from Swedbank:

• Payment Initiation API for Payment Initiation Service Providers (PISP)
• Account Information API for Account Information Service Providers (AISP)

The same set of APIs is available for our four markets: Sweden, Estonia, Latvia and Lithuania.

With the APIs you can:

• Get a list of reachable accounts (AISP)
• Initiate payments on the customer's behalf (PISP)
• Get balances for a given list of accounts (AISP)
• Get transaction information for a given account (AISP)

The API provides data for both Swedish and Baltic customers of Swedbank. More detailed information is available in the API documentation.

Currently, we support both the redirect and decoupled method for Estonia, Latvia and Lithuania and the redirect method for Sweden. Customers can give consent or authorise payments using the following SCA methods from Swedbank: BankID, Mobilt BankID, (Sweden) and Smart-ID, Mobile-ID, PIN generator, ID-card (Baltics).

Swedbank has offered eIDAS certificates support in our test environment since February 2019.

The EU has issued the PSD2 regulation, which strives to make payments safer, increase consumer protection, and foster innovation and competition while ensuring an equal playing field for all market players, including new ones. It means that:

• The customer can grant third-party service providers access to the customer's payment account information at the customer's bank;
  
• The customer can grant third-party service providers permission to initiate payments from the customer's Swedbank bank accounts;
  
• Authentication processes related to information and transactions must adhere to updated strong authentication standards.
  

Creating APIs that allow third parties to integrate their services with Swedbank and, with customer consent, use their account information or initiate payments, is at the core of Open Banking. But that is just the first step of opening the bank's services – we invite any fintech with ideas on how to collaborate to deliver interesting customer solutions to approach us for Premium API access beyond the PSD2 scope.

You can find the respective information on PSD2/ Open Banking on local Swedbank websites and in respective languages in the links below.

Sweden

Latvia

Lithuania

Estonia

Here is more information provided by the European Commission about the directive.

By integrating with our PSD2 API, you can connect to customers in our four home markets (Sweden, Estonia, Latvia and Lithuania) and the following Savings Banks on the Swedish market:

Bergslagens Sparbank AB

Bjursås Sparbank

Dalslands Sparbank

Ekeby Sparbank

Falkenbergs Sparbank

Fryksdalens Sparbank

Hälsinglands Sparbank

Häradssparbanken Mönsterås

Högsby Sparbank

Ivetofta Sparbank i Bromölla

Kinda Ydre Sparbank

Laholms Sparbank

Lekebergs Sparbank

Leksands Sparbank

Lönneberga-Tuna-Vena Sparbank

Markaryds Sparbank

Mjöbäcks Sparbank

Norrbärke Sparbank

Orusts Sparbank

Roslagens Sparbank

Sala Sparbank

Sidensjö Sparbank

Skurups Sparbank

Snapphanebygdens Sparbank

Sparbanken Boken

Sparbanken Alingsås AB

Sparbanken Eken AB

Sparbanken Gotland

Sparbanken Göinge AB

Sparbanken i Enköping

Sparbanken i Karlshamn

Sparbanken Lidköping AB

Sparbanken Nord

Sparbanken Rekarne AB

Sparbanken Skaraborg AB

Sparbanken Skåne

Sparbanken Tranemo

Sparbanken Tanum

Sparbanken Sjuhärad AB

Sparbanken Västra Mälardalen

Sörmlands Sparbank

Södra Dalarnas Sparbank

Södra Hestra Sparbank

Sölvesborg-Mjällby Sparbank

Tjustbygdens Sparbank AB

Tidaholms Sparbank

Tjörns Sparbank

Ulricehamns Sparbank

Valdemarsviks Sparbank

Vadstena Sparbank

Westra Wermlands Sparbank

Varbergs Sparbank AB

Vimmerby Sparbank AB

Virserums Sparbank

Ålems Sparbank

Åse Viste Sparbank

Åtvidabergs Sparbank

Ölands Bank AB

A customer can only make payments to accounts that have been added to the customer's recipient list. The recipient list is a step to mitigate fraud and protect the customer. To add an account to the customer's recipient list, the customer must sign the action with the PIN Calculator or extended mobile BankID. This means that to make a payment through the API to a new account, the account must first be added to the recipient list. The functionality works in the same way in all our own channels and the API. When the account has been added to the recipient list, it is possible to make payments both in Swedbank's own channels and in the API. The use of the recipient list has been very effective in our work to mitigate fraud and in protecting the customer.

No, there is no need to sign any agreement. It is enough for you to get the appropriate FSA licence and follow these steps.

The Swedbank PSD2 API provides services optimised for PSU and TPP experience; it allows you to get all transaction lists in a single request. This solution optimises performance and allows you to implement pagination in a way that matches your application needs. Hence, PSD2 API pagination is not necessary and therefore not supported. More information is provided in our support channel, which you can find in Paragraph “Transaction list with data older than 90 days” on the link here.

The RTS (Commission Delegated Regulation (EU) 2018/389) specifies two types of requests:

1. Requests where the PSU is actively involved (Art. 36(5)(a)); 
2. Requests where the PSU is not actively involved (Art. 36(5)(b)).

The first type of request has no limitation in terms of the number of requests. The second type can be requested four times/day for every PSU by the TPP.

We have applied for a fallback exemption to our local FSAs, and it has been approved for Estonia, Latvia and Lithuania. Documentation for our fallback solution in Sweden is provided for licensed TPPs – please contact openbanking@swedbank.com. Access to our online bank or screen-scraping is not a proper interface for TPPs.

Yes, decoupled SCA flow is available for Estonia, Latvia, Lithuania and Sweden. The implementation is described in our documentation section 8.3 “Decoupled Approach”.

“There is already a possibility to add the scope to ask for consent for transactions beyond 90 days. You can add the extra scope in the request and use the same SCA as for the account transactions within 90 days. After 90 days have expired, you can renew the consent again with the additional scope.

It is described in our documentation on page 6 and onwards.”

Question: We want to implement a PIS-only flow where the TPP does not have to send the payer account information beforehand. Can you offer a drop-down for accounts in the redirect flow for the PSU to choose account?

Response: This was implemented during Q1 2021. The PISP can now implement a payment flow where the PSU chooses payment account and a payment can be made without sharing account information with the TPP. This is only available in our redirect flow because of limitations in the SCA methods (Mobile BankID and SmartID) that make it impossible for the PSU to choose different options while signing.

Question: Within Swedbank (Swedish market), the PSU needs to add the recipient account for a payment to an approved account list (and sign the request with an SCA). We consider this to be an obstacle in the API. Can you remove the necessary approval of the recipient account for the PSU?

Response: “The functionality to add a recipient account to an approved account list has been implemented in Swedbank channels (in Sweden) for many years. It is part of our fraud protection. We have the same flow in our PSD2 API as we have in our own channels, hence it can’t be considered to be an obstacle.

Since we have received many questions about the functionality and that TPPs would like to remove the necessary friction for the PSU, we are evaluating different solutions to simplify the flow while maintaining fraud protection, security and risk level. In the future it is possible that we will offer a partnership agreement that adds functionality for the TPP with an agreement. If you are interested in such functionality, please let us know by sending an email to openbanking@swedbank.com and we will let you know if we provide options.”

Question: We would like to have the account holder name accessible via the PSD2 API. We consider it to be a requirement in the RTS (EU) 2018/389 for Account Servicing Payment Service Providers (“ASPSPs”) to make the information available to Account Information Service Providers (“AISPs”) and Payment Initiation Service Providers (“PISPs”).

Response: "Regarding providing the account holder name upon execution of a payment initiation, Swedbank acknowledges that the DG FISMA (through the EBA) has stated in Q&A 2018_4081, that the ASPSP shall, immediately after receipt of the payment order, provide PISPs with the same information on the initiation and execution of the payment transaction provided or made available to the PSU when the transaction is initiated directly by the latter. Hence, the ASPSP shall, immediately after receipt of the payment order, provide the name of the payer (PSU) to the PISP via the dedicated interface if the name is included in the information on the initiation and execution of the payment transaction provided or made available to the PSU when the transaction is initiated directly by the latter.

Swedbank does not, to our immediate knowledge, currently include the PSU’s name in the information on the initiation and execution of a payment transaction. If you have observed such information in the payment flows of the customer-facing interfaces, please provide us with information thereof, as this might be an error that needs rectification.

 

Also, please note that the current functionality of the Swedbank API, as agreed in discussions in API Forum between banks and TPPs, the personal identity number of the PSU is “locked in” upon entry in the beginning of the flow, thereby indirectly verifying the identity of the PSU, since a mismatch of the entered personal identity number and the SCA performed would render an error message. This functionality is described in the Swagger documentation (see PSU-ID reference).”

Question: The EBA Opinion from June 2020 indicates that it should be possible for a PISP to initiate a payment with only one SCA if all the payment data needed is provided. How is that implemented?

Response: If the TPP provides all data for a payment (such as the payer account), it can be posted and initiated with one SCA in the API. However, there is a requirement to provide a valid token before posting a payment initiation. This is a feature that the API and our own channels have in common. In fact, in our own channels we don’t keep the token active for 90 days, the user has to obtain a token for each session, while in PSD2 API the same token can be re-used for 90 days.

During the user authentication (via issued token), many security and fraud prevention checks take place. Allowing payment initiation without user authentication (through a token) would compromise the levels of security in a way that we don’t want to risk, not in our own channels and not in the API. When we have had discussions with supervisors on this topic, we have also reached the conclusion that, for the sake of maintaining security, it is a valid point to keep the flow as it is in our channels.

Question: When aggregating account information in the API, a different number of SCAs is needed on the different markets. Why is that?

Response: The functionality in our API is the result of how the PSD2 regulation is implemented in our different markets. Therefore, local requirements are taken into consideration and the functionality we provide is agreed with the local FSAs. This means that, in Sweden, only one SCA is needed (which combines authentication and signing). Estonia, Latvia and Lithuania have one SCA for authentication in common (PIN1). For consent to share account information, PSUs in Estonia and Lithuania are required to do two SCAs, but in Latvia only one SCA is required (and replaced it with a confirmation step).

Yes, if you are interested in integrating with PSD2 APIs, follow the steps outlined here. We are always open to mutually interesting cooperation with third parties. If you have a solution beyond the PSD2 scope, you can fill out the partner application form here.

No. These are Swedbank’s proprietary prices based on market data obtained from Swedbank’s counterparties on the interbank market. As such, they give a good indication of “where the market currently is” but they will not necessarily be aligned with the rates from the ECB or from any other source.

No, not directly. These rates are only for information purposes and are not to be considered tradable.

In the financial markets, price-makers such as banks typically quote BID and ASK prices. BID is typically the price that the bank is prepared to buy the asset/instrument/commodity for, and ASK is the price the bank is prepared to sell it for. The difference between BID and ASK is typically referred to as the spread. MID in this context is simply the average of BID and ASK, and as such gives an indication of what an asset/instrument/commodity trades for in the market but is not in itself a tradable price.

Yes. At this point the service is only available for customers of Swedbank AB Sweden and Swedbank AB Norway who already have access to the FX Trade Service. If that description fits you, you should be good to go. If it does not, we are of course more than willing to help you get onboard, but then we suggest you contact openbanking@swedbank.com or Customer Service Centre – Corporate at +46 (0)771-33 44 33 before initiating the onboarding process on Open Banking.

No. There is no licence fee to access the Market Orders service as such. Getting access to the service does, however, require a Transport Layer Security (TLS) client certificate for authentication of the customer. Swedbank Open Banking will be happy to evaluate whether any TLS certificate that the customer already has will be sufficient for this purpose, but if that is not the case, a small fee may need to be paid to a third-party Certification Authority (CA) to procure such a certificate. Swedbank Open Banking will be available for advice also on suitable CAs. Please contact openbanking@swedbank.com if needed.

The Market Orders service is a simple API that can be used to send FX orders to be executed at prevailing market rates. Simplicity has been prioritised, and at this point there is no advanced order-management functionality in place. It is of course possible to use the Indicative Rates service in conjunction with the Market Orders service to obtain an indicative quote before placing an order.
Swedbank will also launch more RestFX services and more advanced RestFX and BalanceFX functionality in the future.