Skip to main content

​
Overview

This glossary defines key terms used throughout the Yapily documentation. Terms are organised alphabetically for easy reference.

​
A

​
Account Information Service Provider (AISP)

Definition: A licensed third-party provider authorised to access customer account and transaction data with explicit consent. Context: If you’re building applications that read banking data (e.g., budgeting apps, credit assessment tools), you operate as an AISP. With Yapily Connect, you can use Yapily’s AISP license without obtaining your own. Related:

​
Account Information Services (AIS)

Definition: Services that retrieve account and transaction data from banks on behalf of customers with their consent. Context: AIS is one of the two main categories of Open Banking services (the other being PIS). Yapily’s Data Access and Data Plus products enable you to provide AIS. Use Cases: Account aggregation, transaction categorisation, financial insights, affordability checks Related:

​
Application ID

Definition: A unique identifier (UUID format) assigned to your application in the Yapily Console, used for API authentication. Context: Every API request to Yapily requires authentication using your Application ID and Secret. You can create multiple applications for different environments (sandbox, production). Example: a7f31e45-9c51-4e97-b5e8-8c4d9a7b3f2a Related:

​
Authentication

Definition: The process of verifying a user’s identity (proving who you are). Context: In Open Banking, banks authenticate customers using Strong Customer Authentication (SCA) before granting consent to TPPs. Authentication is different from authorisation. Example: Logging into your bank with username, password, and SMS code. Related:

​
Authorisation

Definition: The process of granting permission to access resources or perform actions (proving what you’re allowed to do). Context: After authenticating, customers authorise TPPs to access specific data or initiate payments. In Yapily, this involves redirect flows where customers consent at their bank. Difference from Authentication: Authentication proves identity; authorisation grants permissions. Related:

​
B

​
Beta

Definition: A Beta version of a product or feature provides useful capabilities, but may have limited coverage or functionality or require further work before general release. Context: Beta features are available in production to all customers, but may need minor adjustments or additional features before the final release.

​
Bulk Payments

Definition: A payment type that allows multiple payments to be initiated in a single request. Context: Use bulk payments for scenarios like payroll processing, supplier payments, or refund batches. Bank support for bulk payments varies by institution. Related:

​
C

Definition: Explicit permission from a customer (PSU) authorizing a TPP to access their account data or initiate payments. Context: Consent is the foundation of Open Banking. Every data access or payment requires customer consent, which can be revoked at any time. Consent has a defined scope (what data/accounts) and duration (how long access lasts). Key Requirements:
  • Must be explicit and informed
  • Customer must authenticate with bank (SCA)
  • Can be revoked at any time
  • Has defined scope and expiration
Related:
Definition: A unique token issued by Yapily after successful user authorisation, used to access banking data or execute payments. Context: After a customer authorises access at their bank, Yapily issues a consent token that your application uses in API requests. The token is scoped to specific accounts and permissions. Example Usage: 
curl -X GET https://api.yapily.com/accounts \
  -H "Authorisation: Bearer YOUR_ACCESS_TOKEN" \
  -H "consent: YOUR_CONSENT_TOKEN"
Related:

​
D

​
Data Plus

Definition: Yapily’s suite of data enrichment and insights products that enhance raw banking data. Context: Data Plus includes categorisation, balance prediction, financial profiling, and transaction group analysis. These features help you build smarter financial applications. Products:
  • Transaction categorisation
  • Merchant name
  • Recurring payments
  • Payment processor
Related:

​
Decoupled Authorisation

Definition: An authorisation flow where the customer completes authentication on a separate device from where they initiated the request. Context: Some banks support decoupled flows where the customer receives a push notification on their mobile banking app to authorise a request initiated on desktop. Example: Customer initiates payment on laptop, receives push notification on phone, authorises on phone. Related:

​
E

​
Embedded Flow

Definition: An authorisation flow where the bank’s authentication form is displayed within your application interface, rather than redirecting to the bank’s website. Context: Embedded flows provide a more seamless user experience but require implementing the bank’s UI within your app. Not all banks support embedded flows. Related: Note: Hosted Pages customers don’t need to implement embedded flows - Yapily handles this.

​
H

​
Hosted Pages

Definition: Yapily’s pre-built, compliant user interface for payment and data consent flows. Context: Instead of building your own UI and implementing authorisation flows, use Hosted Pages for faster time-to-market. Yapily handles bank selection, consent screens, and authorisation flows while you focus on your core product. What Yapily Handles:
  • Bank selection interface
  • Consent screen UI
  • Redirect and embedded flows
  • SCA handling
  • Bank-specific requirements
What You Still Do:
  • API authentication
  • Create payment/consent requests
  • Handle callbacks
  • Access banking data/payment status
Related:

​
I

​
Idempotency

Definition: The property that ensures an operation can be performed multiple times with the same result, preventing duplicate transactions. Context: Yapily payment requests require an idempotency ID to prevent duplicate payments. If you retry a request with the same idempotency ID, you’ll get the same result without creating a duplicate payment. Example: 
{
  "paymentIdempotencyId": "payment-12345-20250111",
  "amount": { "amount": 100.00, "currency": "GBP" }
}
Related:

​
Institution

Definition: A bank or financial institution that provides Open Banking APIs. Context: In Yapily’s platform, each bank is represented as an “Institution” with a unique ID (e.g., hsbc-sandbox, barclays-ob). You select which institution to connect to when creating consent or payment requests. Key Properties:
  • Institution ID (unique identifier)
  • Supported features (payments, data, VRPs)
  • Countries served
  • Authorisation flow types supported
Related:

​
O

​
Open Banking

Definition: A regulatory framework that allows consumers to grant third-party providers access to their bank account data or initiate payments through secure APIs. Context: Open Banking is the foundation of Yapily’s platform. Mandated by PSD2 in Europe, it enables innovation in financial services while maintaining security and regulatory compliance. Key Principles:
  • Customer consent required
  • Strong customer authentication (SCA)
  • Regulatory oversight
  • Standardized APIs
  • Revocable access

​
Open Banking Implementation Entity (OBIE)

Definition: The UK standards body responsible for defining Open Banking specifications and ensuring consistent implementation across UK banks. Context: OBIE created the UK Open Banking Standard, which UK banks must implement. Yapily complies with OBIE standards when connecting to UK banks. Related:

​
P

​
Payment Initiation Service Provider (PISP)

Definition: A licensed third-party provider authorised to initiate payments from customer bank accounts with explicit consent. Context: If you’re building applications that initiate payments (e.g., e-commerce checkouts, bill payment services), you operate as a PISP. With Yapily Connect, you can use Yapily’s PISP license. Related:

​
Payment Initiation Services (PIS)

Definition: Services that initiate payments directly from customer bank accounts with their consent. Context: PIS is one of the two main categories of Open Banking services (the other being AIS). Yapily’s payment products enable you to provide PIS. Use Cases: E-commerce checkout, bill payments, peer-to-peer transfers, recurring subscriptions Related:

​
Payment Service User (PSU)

Definition: The customer or business that uses payment services - the end user who grants consent to TPPs. Context: In Open Banking flows, the PSU is the person who owns the bank account and authorises data access or payments. Also referred to as “the customer” or “the user.”

​
Pre-Authorisation

Definition: An authorisation flow where the customer provides credentials to the TPP before being redirected to the bank. Context: Some banks require pre-authorisation where you collect customer identifiers (e.g., account number, sort code) before initiating the authorisation flow. This is bank-specific. Related:

​
Private Beta

Definition: An experimental version of a product or feature available only to invited customers. Context: Private Beta versions can only be accessed by authorised applications. Contact your customer success manager if you’re interested in participating in Private Beta programs.

​
PSD2 (Payment Services Directive 2)

Definition: The European Union regulation that mandates Open Banking, requiring banks to provide APIs for licensed third-party providers. Context: PSD2 came into effect in September 2019 and is the legal foundation for Open Banking in Europe. It defines requirements for SCA, data access, payment initiation, and consumer protection. Key Requirements:
  • Banks must provide Open Banking APIs
  • Strong Customer Authentication (SCA) required
  • TPPs must be licensed by regulators
  • Customer consent is mandatory

​
R

​
Redirect Flow

Definition: An authorisation flow where the customer is redirected to their bank’s website or app to authenticate and grant consent. Context: Redirect flow is the most common authorisation method. Your application redirects the customer to the bank, the bank authenticates them (SCA), and the customer is redirected back to your app with consent. Flow Steps:
  1. Create payment/consent request with Yapily
  2. Receive authorisation URL
  3. Redirect customer to authorisation URL (bank website)
  4. Customer authenticates at bank (SCA)
  5. Customer grants consent
  6. Bank redirects customer back to your callback URL
  7. Fetch payment status or account data
Related:

​
Regulatory Technical Standards (RTS)

Definition: Detailed technical requirements specifying how PSD2 must be implemented, including Strong Customer Authentication (SCA) rules. Context: RTS defines specific security and technical requirements for Open Banking implementations across the EU. Related:

​
S

​
Strong Customer Authentication (SCA)

Definition: A security requirement under PSD2 that customers must authenticate using at least two of three factors: knowledge (password), possession (phone/token), inherence (biometrics). Context: Banks enforce SCA during Open Banking authorisation flows to verify customer identity. Common SCA methods include password + SMS code, password + biometric, or mobile app push notifications. Three Authentication Factors:
  1. Knowledge: Something you know (password, PIN)
  2. Possession: Something you have (phone, hardware token)
  3. Inherence: Something you are (fingerprint, face recognition)

​
T

​
Third Party Provider (TPP)

Definition: A licensed company authorised to access customer banking data (AISP) or initiate payments (PISP) through Open Banking APIs. Context: Yapily is a TPP aggregator - instead of integrating directly with each bank, you integrate with Yapily and access our network of bank connections. You can either use Yapily’s TPP license (Yapily Connect) or your own. TPP Types:
  • AISP: Account Information Service Provider (data access)
  • PISP: Payment Initiation Service Provider (payments)
  • AISP + PISP: Dual license (both data and payments)
Related:

​
U

​
User UUID

Definition: A unique identifier you assign to each of your users for tracking and managing their Yapily interactions. Context: When creating payment or consent requests, you provide a User UUID to associate the request with a specific user in your system. This helps with auditing, analytics, and managing user consents. Example: user-12345 or 550e8400-e29b-41d4-a716-446655440000 Best Practice: Use your internal user ID as the User UUID for easy correlation. Related:

​
V

​
Validate

Definition: Yapily’s identity verification product that confirms a person’s identity by matching their name against bank account holder information. Context: Use Validate for KYC (Know Your Customer) requirements, account ownership verification, and fraud prevention. It retrieves account holder identity data and performs name matching. Use Cases:
  • Onboarding verification
  • Account ownership confirmation
  • Anti-fraud checks
  • Regulatory KYC compliance
Related:

​
Variable Recurring Payments (VRPs)

Definition: A payment type that allows you to initiate multiple payments of varying amounts from a customer’s account under a single consent (mandate). Context: VRPs enable flexible recurring payments for subscriptions, savings sweeps, loan repayments, or variable bills. Unlike traditional Direct Debits, VRPs are instant and customer-controlled. Key Features:
  • Variable payment amounts
  • Customer-defined limits
  • Instant execution
  • Revocable consent
  • Currently UK only, limited bank support
Related:

​
W

​
Webhook

Definition: An HTTP callback that Yapily sends to your server when specific events occur (e.g., payment completed, consent authorised). Context: Instead of polling Yapily’s API for status updates, configure webhooks to receive real-time notifications when payment or consent status changes. Common Events:
  • payment.status.updated - Payment status changed
  • account-authorization.status.updated - Consent status changed
  • payment.completed - Payment successfully completed
  • payment.failed - Payment failed
Related:

​
Y

​
Yapily Connect

Definition: Yapily’s service that allows you to use Yapily’s AISP/PISP license instead of obtaining your own, enabling faster time-to-market without regulatory burden. Context: With Yapily Connect, you don’t need to register with banks individually or obtain your own Open Banking license. Yapily handles all regulatory requirements. However, consent screens will show Yapily branding alongside yours. Benefits:
  • No license procurement needed
  • No bank registration required
  • Start in days, not months
  • Yapily handles compliance
Trade-offs:
  • Yapily branding in consent screens
  • Using Yapily’s regulatory relationship
Related:

​
Additional Resources

Getting Started

Begin your integration journey

API Reference

Complete API documentation

Payments

Payment initiation products

Data Access

Account and transaction data

Support

Get help from our team

Community

Join our developer community