The Key Players: PISPs, AISPs and PIISPs

A payment initiation service provider, known as a PISP, starts a payment from a customer bank account on the customer instruction. At an online checkout, the customer chooses pay by bank, picks a bank, is sent to the bank to authenticate, and returns to the retailer with the payment started. The PISP sends the payment instruction to the bank through the bank API, and the bank executes it as a normal credit transfer. The PISP never holds the customer money, because the funds move directly from the customer account to the merchant account. Some PISPs use tokenised payments, where a single use token stands in for the account details, so the merchant never sees the customer account number. The PISP earns its place by making the checkout faster and cheaper than a card, and by giving the merchant a payment confirmation within seconds. An account information service provider, known as an AISP, reads account data with the customer consent and shows it back in a useful form. A budgeting app might pull transactions from a current account, a savings account and a credit card, then sort them into rent, food, transport and subscriptions. A lender might use an AISP to check income and spending before approving a loan, instead of asking for paper statements. The AISP may read balances, transactions and account holder details, but it may not start a payment, and it may only read the data the customer agreed to. Consent usually lasts up to 180 days and must be renewed, and the customer can revoke it at any time. A payment instrument issuer service provider, known as a PIISP, is a card issuer that checks whether a customer has enough funds before it authorises a card payment. When a customer pays by card, the issuer asks the account holding bank whether the balance covers the amount, and the bank answers yes or no without revealing the balance. This check helps the issuer decide whether to approve the card payment, and it reduces the risk of an overdraft or a declined payment at the till. The PIISP does not move money and does not read transaction history, it only asks a single question about available funds, and it needs the customer consent to ask it. All three players must be licensed or registered with a national regulator, and the bank must check that licence before it allows access. In Europe, the regulator keeps a register of payment institutions, and the bank API checks the provider certificate on every call. If a licence is revoked, access stops at once, and the customer must be told. The licence also decides what the provider may do, so an AISP cannot start a payment, and a PISP cannot read a full transaction history. For a business analyst, the licence type is a requirement, not a detail, because the consent screen, the API scope, and the error handling all change with it. When a PISP sends a wrong amount the PISP is at fault, and when the bank executes a correct instruction wrongly the bank is at fault. A worked example shows the players in action. A customer wants to pay a merchant using a payment initiation service provider, a PISP, and also wants to see all their accounts in a budgeting app, which is an account information service provider, an AISP. The PISP and the AISP are different companies, with different licences, and they do different things. The PISP initiates payments on the customer's behalf, with the customer's consent, and is liable if it initiates a payment the customer did not agree to. The AISP reads account information, with the customer's consent, and cannot move money. A third player, the payment initiation service provider that also offers account information, must hold both licences. The bank must check the licence of each player before allowing it to call its API, and must reject a call from a player whose licence does not cover the operation it is requesting. For a business analyst, the requirement is to define the player types, the licences, and the check the bank performs on each call. A failure scenario tests the licence check. A company that holds only an AISP licence calls the bank's payment initiation API to create a payment. The bank must reject the call with a 403 Forbidden response, because the company is not licensed to initiate payments. The bank must also log the attempt, because a company that tries to do something it is not licensed to do may be acting fraudulently or may have a defect in its integration. The licence check is not a formality; it is the control that enforces the regulatory boundary between reading account information and moving money. Last reviewed 7 November 2026. Further reading: PSD2 Directive (EU) 2015/2366; European Banking Authority register of payment institutions. Worked example with numbers: a customer buys EUR 240 of kitchen goods from an online retailer, chooses pay by bank at checkout, picks the bank, authenticates in the banking app, and returns to the retailer, which receives the EUR 240 the same day. The PISP, a licensed provider called PayBridge, started the payment, the bank debited the customer account, and the retailer bank credited the retailer account, all without a card. The AISP in the same journey is a budgeting app that reads the customer transactions and shows that EUR 240 went to kitchen goods, while the PIISP is a card issuer that checks whether the customer has enough funds before it authorises a card payment, so that a card payment is not approved when the account is empty. Failure and recovery: the three players fail in different ways, and each failure needs a different recovery. If the PISP sends a payment instruction with a wrong amount, the bank must reject it, because the amount the customer approved and the amount in the instruction must match, and the customer must approve again with the right amount. If the AISP reads data it was not given consent for, the bank must block the access and tell the customer, because the consent is the only permission the AISP has. If the PIISP checks the wrong account, it may approve a card payment that the customer cannot afford, and the recovery is a corrected account link and a review of the payments that were approved wrongly. For a business analyst, product owner or subject matter expert, the player requirement must state the three roles, PISP starts payments, AISP reads data, PIISP checks funds before a card payment, and must state that each one needs a licence or registration with a national regulator. The requirement must also state that the bank checks the provider certificate on every call, and must name the API that each player uses, because a PISP that calls an account information API will fail, and an AISP that calls a payment initiation API will fail. The test pack must include a PISP payment, an AISP read, a PIISP funds check, and a provider with no licence, because each case exercises a different player. Source: PSD2; European Banking Authority; last reviewed 7 November 2026.