Sorry, you need to enable JavaScript to visit this website.

Frequently Asked Questions

The following APIs are available:

  • Accounts
  • Payments
  • Confirmation of Funds
  • AIB (NI) Branch Locator
  • Product Details
  • ATM Locator

If you are interested in the APIs currently available for, Allied Irish Bank (GB) please visit the website.

Further information regarding our APIs can be found on the ‘API Products and Benefits’ page.

To register for access to the Developer Portal simply click the ‘Register’ button at the top of the screen and fill out the form to create an account. Check for an email with an activation link. Once you have activated your account and created a password, you will then be able to log in and access our APIs.
For further details see the ‘Getting Started’ section.
Security is important to us. The sandbox and the live environment meet the latest security standards. We’ve employed the 0Auth 2.0 consent model to enable customers to grant access to third party service providers (your application) in a clear and secure manner. 

Our sandbox provides an opportunity for developers to test their app before building in production. The sandbox is a safe, secure environment where you can test your apps functionality and test our API integrations with your apps.

Please refer to the getting started page which explains how you can onboard and get access to our sandbox environment

To obtain an Open Banking SSA please visit the Open Banking website where you will find details of the Open Banking enrolment process and steps to get your software statement.

No, you cannot re-use the same application across AIB Group. You will need to log in separately and add a new application in each developer portal.

1. eIDAS QWAC. This is the certificate to use in the MATLS network level connection at runtime.

2. A recognised certificate capable of creating a digital signature. The digital signature is required during the OIDC client authentication using the private_key_jwt client authentication method. This certificate can be an eIDAS QSealC or a certificate signed by a recognised public Certificate Authority.

Please note that we are aligned to FCA guidance during the “Adjustment Period” up until March 2020 and as such if you have not yet obtained an eIDAS certificate we will accept the use of equivalent certificates (such as open banking certificates) as long as they enable secure identification.

If you come across a bug please contact our team at

What changes are AIB making?

The OBIE Read/Write API specification (in v3.0, 3.1, 3.1.1, 3.1.2 and 3.1.3) require both TPPs and ASPSPs to sign all payment messages. The OBIE Specification makes use of the "b64" header parameter and this controls whether the usage is Base64URL encoded before signing. This header is not widely supported in the majority of JWT libraries and therefore requires us to make a change.

When are we making this change?

The change will be implemented in AIB's Sandbox environment on June 1st 2020 with a view to implementing to live APIs on the 16th of June 2020.

What does this mean for you?

You as a TPP, under the specification mentioned above must not validate the message signature during the period of the waiver.

OBIE will update the conformance harness to not generate or validate the message signature during the period of the waiver. After expiration of this waiver, TPPs must support message signatures as defined in their Payment Initiation APIs implementation. We as an ASPSP will include details of which version we support in our API documentation which can be found on our Developer Portals.

For further information on Waiver007 please refer to the Open Banking documentation in the following link:

If you have any questions or concerns, please don’t hesitate in reaching out to our support mailbox

Additional information

  • Our supported version of payments endpoints is currently v3.1.1
  • To validate signatures, AIB are expecting the following headers in x-jws-signature format:
    • Validation will fail if x-jws-signature is NOT sent or signature is invalid
    • A signature will be deemed invalid if the b64 header is true or missing, for example, if the payload was Base64URL encoded before signing.
    • The JWS must contain the following headers {"b64":false, "crit":["b64"]}
  • Where required, AIB will send the signature for all existing API endpoints that require messages to be signed in request and or response
  • Please note, this signature will NOT be Base64URL encoded.
  • The JWS will contain these headers {"b64":false, "crit":["b64"]}
  • This will be applicable for all existing API endpoints that require messages to be signed in request and or response.

If you have any further questions please don’t hesitate to contact us at

Improvements to the AIB redirection journey

As part of our ongoing commitment to deliver a seamless and secure redirection journey for our customers, AIB will be simplifying the direct access flows within our Internet and Business Banking Channels. This will mean more simplified flows and quicker navigation for customers. These updates will be made available in March.

The performance and availability statistics of our dedicated interface can be found here


We want to let you know of an upcoming change and how it impacts you as a TPP.  The change is to uplift to 3.1.4 as prescribed by Open Banking. This will be completed the week of the 23rd November 2020.

Migration to the Open Banking 3.1.4 API Specification

As part of our migration to the Open Banking 3.1.4 API specification we will be making changes to our AIS, PIS and CBPII API’s. This will include mainly non-breaking changes.

We wanted to give early visibility of one breaking change to any TPP’s using our international endpoints.

What are we changing and why?

  • As part of our alignment to the 3.1.4 PIS specifications we will be changing the behaviour and validation of one field in the international payment consent payload request.
  • Today we require TPP’s to always provide the  field - OBInternational3/CreditorAgent/PostalAddress/Country
  • This field will no longer be mandatory and will be optional
  • A specific field has been introduced for the purpose of identifying the credit account country called - OBInternational3/DestinationCountryCode
  • This field will be mandatory for all international payments
  • We will be updating our developer portal documentation and sandbox services to reflect this change.

If you have any questions or concerns, please don’t hesitate in reaching out to our support mailbox

We appreciate your co-operation with this.

Best regards,