LESSON 2: Open Banking (PSD2), Account Information Services (AIS), Payment Initiation Services (PIS), and Banking as a Service (BaaS)

1. LEARNING OBJECTIVES

By the end of this massive, 20+ page lesson, you will be able to:

Understand the PSD2 (Revised Payment Services Directive) regulatory framework and how it transformed European banking.
Distinguish between an AISP (Account Information Service Provider) and a PISP (Payment Initiation Service Provider).
Explain the technical blueprint of Open Banking APIs, specifically the OAuth 2.0 flow used to share financial data securely.
Map out the architectural difference between a traditional bank, an Open Banking Aggregator, and a BaaS (Banking as a Service) provider.
Understand how BaaS enables non-bank FinTechs (e.g., Uber, Shopify, Revolut) to offer core banking services (checking accounts, debit cards, lending) without becoming a licensed bank.
Analyze the risks of Open Banking, including the threat of “API Abuse” and the strict liability on PISPs under PSD2.
Build a complete, beginner-friendly Python simulation using FastAPI to demonstrate the OAuth 2.0 Authorization Code Flow used in Open Banking.
Write a script to mimic a Plaid-like Aggregator that connects a user’s bank account to a third-party finance app via API.

2. THE REGULATORY EARTHQUAKE: PSD2

2.1 The “Data Monopoly” Problem
Historically, a customer’s financial data belonged solely to their bank. Banks held a monopoly over user transaction histories, balances, and recurring payments. This meant that if a user wanted to use a third-party app (like Mint or YNAB) to track their spending, they had to manually enter their expenses, or worse, give their primary bank username and password directly to the third-party app (a massive security risk known as “screen scraping”).

2.2 The Birth of Open Banking
In 2018, the European Union passed PSD2 (Revised Payment Services Directive 2). This law fundamentally changed the global financial landscape.
PSD2 mandates that banks must unlock their customer data and expose it via secure, standard APIs to authorized third-party providers (TPPs)—provided the customer actively consents.
This forced banks to open their “digital vaults” and share transaction history (AIS) and initiate payments (PIS) via APIs, ending the data monopoly.

2.3 The Global Ripple Effect
While PSD2 is an EU law, it triggered global adoption.

UK: The Open Banking Implementation Entity (OBIE) defined the technical specs for the UK.
US: While not legally mandated by federal law, the US saw the rise of the CFPB (Consumer Financial Protection Bureau) publishing “Section 1033” which essentially enforces a similar Open Banking framework. Additionally, private market forces (e.g., Plaid, Yodlee) have made Open Banking the de facto standard in the US to avoid the risks of screen scraping.

3. THE ACTORS IN OPEN BANKING

3.1 ASPSP (Account Servicing Payment Service Provider)
This is the traditional bank (e.g., Chase, Barclays, Deutsche Bank). They hold the customer’s money and are legally required under PSD2 to build public-facing REST APIs that expose two specific services:

AIS (Account Information Service): The ability for the bank to share the customer’s account balance and transaction history.
PIS (Payment Initiation Service): The ability for the bank to execute a payment order on behalf of a third-party app.

3.2 TPP (Third Party Provider)
These are the FinTech apps built by startups. Under PSD2, they fall into two categories:

AISP (Account Information Service Provider): An app like Mint, YNAB, or Plaid. They can read your balance and transactions.
PISP (Payment Initiation Service Provider): An app like PayPal or Klarna. They can initiate a wire transfer directly from your bank account to a merchant, bypassing the credit card networks entirely.

3.3 The “Screen Scraping” Ban
Under PSD2, banks are legally required to provide an API. Therefore, screen scraping (where apps store your bank password and pretend to be a user using a headless browser) was banned. If a TPP wants user data, they must use the PSD2 API, ensuring the customer’s password never leaves the bank’s own domain.

4. THE OPEN BANKING AUTHENTICATION FLOW (OAUTH 2.0 IN ACTION)

4.1 The Consent & Authorization Code Flow (Refresher)
In Module 8, Lesson 3, we learned the OAuth 2.0 Authorization Code Flow. Open Banking uses the exact same flow, but with highly specific scopes.
Let’s trace a user trying to connect their bank account to a personal finance app (AISP) named “BudgetWise”:

The Request: In the “BudgetWise” app, the user clicks “Connect Bank”. The app redirects the user’s web browser to the bank’s login page, sending:
- response_type=code
- client_id=bw_12345 (BudgetWise’s registered ID)
- redirect_uri=https://budgetwise.com/callback
- scope=accounts:read transactions:read (The specific data BudgetWise is asking for).
The Authentication & Consent: The user logs in to the bank using their own credentials (Bank is ASPSP). After logging in, the bank displays a consent screen: “BudgetWise is asking to view your transaction history. Do you approve?” The user clicks “Approve”.
The Authorization Code: The bank generates a temporary, one-time-use Authorization Code and redirects the browser back to https://budgetwise.com/callback?code=AUTH_XYZ.
The Token Exchange: “BudgetWise” takes the AUTH_XYZ code and its client_secret and makes a backend HTTP POST request to the bank’s /token endpoint. The bank validates the code and issues an Access Token (valid for 90 days) and a Refresh Token to BudgetWise.
The Data Fetch: “BudgetWise” uses the Access Token to make an HTTPS GET request to the bank’s /accounts endpoint. The bank returns a JSON payload containing the user’s balance and the last 100 transactions.

4.2 The “Strong Customer Authentication” (SCA) Rule
Under PSD2, the first time a user connects an AISP or a PISP to their bank, they must perform Strong Customer Authentication (SCA). This is the same 3D Secure we discussed in Lesson 1. The bank will send a push notification to the user’s mobile banking app, requiring a fingerprint or PIN. This mathematically proves the user is present and authorized the API connection, preventing a hacker from secretly linking a victim’s bank account to a malicious app.

5. BANKING AS A SERVICE (BAAS): THE “EMBEDDED FINANCE” REVOLUTION

5.1 The “Bank in a Box”
Open Banking APIs allow read access. But what if an app wants to hold the money and issue physical debit cards?
Traditional FinTech apps (like a specialized app for freelancers) don’t want to spend 5 years and $50 million to become a licensed bank. They use Banking as a Service (BaaS).
BaaS is a cloud-native infrastructure provided by companies like Synapse, Unit, or Galileo.

5.2 The BaaS Architecture

The BaaS Provider: Holds a partnership with a federally chartered, fully licensed bank (e.g., Evolve Bank & Trust, Wells Fargo). The BaaS Provider wraps the bank’s core ledger system (which is usually a 1980s mainframe) into a modern, developer-friendly REST API (often using ISO 20022).
The FinTech App (The “Marketplace”): The marketplace app (e.g., an e-commerce platform like Shopify) signs up with the BaaS Provider.
Embedded Banking: The marketplace app creates a custom debit card for its sellers. The app uses the BaaS API to create sub-accounts, process ACH transfers, and issue physical cards.
The Result: The sellers receive a “Shopify Debit Card”. The banking infrastructure is entirely powered by BaaS, but the branding says “Shopify”. Shopify avoids the massive regulatory overhead of obtaining a bank charter.

5.3 The BaaS Compliance Burden
While BaaS abstracts the core ledger technology, the FinTech app remains 100% liable for compliance. If the marketplace app is used by fraudsters to launder money, the BaaS provider will shut down the app, and the regulators will fine the app’s founders.

The BaaS provider maintains the AML (Anti-Money Laundering) scanning against transactions.
The FinTech app must handle the KYC (Know Your Customer) verifications and send the verified customer data to the BaaS API, which in turn sends it to the chartered bank.

6. BEGINNER HANDS-ON LAB PART 1: SIMULATING AN OPEN BANKING OAUTH2 FLOW

We will now simulate the backend of an Open Banking environment. We will create a FastAPI server that acts as the Bank (ASPSP), and a client script that acts as the third-party App (AISP) requesting transaction data.

(Prerequisites: pip install fastapi uvicorn requests pydantic)

# --- FILE 1: bank_aspsp_api.py (The Bank's Open Banking API) ---
from fastapi import FastAPI, HTTPException, Depends
from fastapi.security import OAuth2PasswordBearer
from pydantic import BaseModel
import secrets
from datetime import datetime, timedelta
from jose import JWTError, jwt

app = FastAPI(title="Bank Open Banking ASPSP API")

# Simulated database of users and their accounts
fake_users_db = {
    "alice": {"password": "secret", "balance": 5000.00, "transactions": [{"id": 1, "amount": -100, "desc": "Amazon"}]}
}
SECRET_KEY = "BANK_SECRET_KEY_123"
ALGORITHM = "HS256"

# --- STEP 1: BANK LOGIN & CONSENT ENDPOINT ---
# In reality, this is an HTML page. We simulate the redirect.
@app.get("/auth/login")
async def login_and_consent(client_id: str, redirect_uri: str, scope: str):
    # Simulate the user successfully logging in and clicking "Approve".
    # The bank generates an Authorization Code.
    auth_code = secrets.token_urlsafe(16)
    # In production, we store {auth_code: client_id, scope, redirect_uri} in a temp table.
    return {"redirect": f"{redirect_uri}?code={auth_code}&scope={scope}"}

# --- STEP 2: TOKEN EXCHANGE ENDPOINT ---
class TokenRequest(BaseModel):
    code: str
    client_id: str
    client_secret: str

@app.post("/auth/token")
async def exchange_token(token_req: TokenRequest):
    # Validate the code and client secrets (skipped for simplicity)
    # Generate Access Token and Refresh Token
    access_token = jwt.encode({"sub": "alice", "scope": "read"}, SECRET_KEY, algorithm=ALGORITHM)
    refresh_token = jwt.encode({"sub": "alice", "type": "refresh"}, SECRET_KEY, algorithm=ALGORITHM)
    return {"access_token": access_token, "refresh_token": refresh_token, "expires_in": 3600}

# --- STEP 3: DATA ENDPOINT (ACCOUNT INFORMATION) ---
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="/auth/token")

@app.get("/api/accounts")
async def get_accounts(token: str = Depends(oauth2_scheme)):
    # Decode and verify the JWT
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
        user_id = payload.get("sub")
        if user_id not in fake_users_db:
            raise HTTPException(status_code=404)
    except JWTError:
        raise HTTPException(status_code=401)
    
    # Return the account data
    return {
        "account_id": f"acc_{user_id}",
        "balance": fake_users_db[user_id]["balance"],
        "transactions": fake_users_db[user_id]["transactions"]
    }

# --- FILE 2: client_budgetwise_aisp.py (The Third-Party App) ---
import requests

# Step 1: The Third-Party App directs the user to the Bank's login page.
auth_url = "http://localhost:8000/auth/login"
params = {
    "client_id": "budgetwise_123",
    "redirect_uri": "http://localhost:8080/callback",
    "scope": "accounts:read"
}
print(f"1. Redirect user to: {auth_url}?client_id={params['client_id']}&redirect_uri={params['redirect_uri']}&scope={params['scope']}")

# Step 2: User logs in, approves, and is redirected back with a Code.
# Simulating the bank's redirect: 
# http://localhost:8080/callback?code=AUTH_XYZ_789&scope=accounts:read
auth_code = "AUTH_XYZ_789"

# Step 3: The App exchanges the Code for an Access Token.
token_url = "http://localhost:8000/auth/token"
token_payload = {
    "code": auth_code,
    "client_id": "budgetwise_123",
    "client_secret": "budgetwise_secret"
}
token_response = requests.post(token_url, json=token_payload)
access_token = token_response.json()["access_token"]
print(f"2. App received Access Token: {access_token}")

# Step 4: The App uses the Access Token to fetch the user's bank data.
data_url = "http://localhost:8000/api/accounts"
headers = {"Authorization": f"Bearer {access_token}"}
data_response = requests.get(data_url, headers=headers)
print(f"3. App fetched user banking data:\n{data_response.json()}")

How to run this simulation:

In terminal 1, run uvicorn bank_aspsp_api:app --reload --port 8000.
In terminal 2, run python client_budgetwise_aisp.py.
The terminal output will show the entire OAuth 2.0 lifecycle: generating the Auth Code, exchanging it for a JWT Access Token, and finally using that token to securely fetch the user’s balance and transaction history. This is exactly how Plaid and Yodlee power apps like Venmo and Robinhood.

7. BEGINNER HANDS-ON LAB PART 2: SIMULATING A BAAS LEDGER ACCOUNT CREATION

To understand how Banking as a Service (BaaS) works behind the scenes, we will simulate a back-end ledger. A FinTech app (like Uber) requests the creation of a sub-account for a new driver, and the BaaS provider generates a unique IBAN (International Bank Account Number) and a balance ledger.

import uuid
import random

# --- STEP 1: THE CORE LEDGER (THE BAAAS PROVIDER) ---
# In a real bank, this is a massive distributed SQL database with transaction logs.
# We simulate it with in-memory dictionaries.
class BaaSLedger:
    def __init__(self):
        self.accounts = {}  # Key: account_id, Value: {balance, holder_name, iban}
        self.transactions = [] # Log of all movements

    def create_sub_account(self, app_name, holder_name):
        """Creates a segregated sub-account for a user."""
        account_id = str(uuid.uuid4())
        # Generate a mock IBAN (International Bank Account Number)
        iban = f"AA{random.randint(100000, 999999)}"
        
        self.accounts[account_id] = {
            "app_name": app_name,
            "holder_name": holder_name,
            "balance": 0.00,
            "iban": iban
        }
        print(f"[BAAS] Created sub-account for {holder_name} on behalf of {app_name}.")
        return account_id, iban

    def credit_account(self, account_id, amount):
        """Simulates a deposit (like a driver receiving a payout)."""
        if account_id not in self.accounts:
            return False
        self.accounts[account_id]["balance"] += amount
        self.transactions.append({
            "type": "CREDIT",
            "account_id": account_id,
            "amount": amount,
            "new_balance": self.accounts[account_id]["balance"]
        })
        return True

    def get_balance(self, account_id):
        return self.accounts[account_id]["balance"]

# --- STEP 2: THE FINTECH APP (EMBEDDED FINANCE) ---
# This is the marketplace app (e.g., Uber, Shopify) that wants to issue a Wallet.
class FinTechMarketplace:
    def __init__(self, baas_provider: BaaSLedger):
        self.baas = baas_provider
        self.name = "RideSharePro"

    def onboard_driver(self, driver_name):
        # The App does KYC checks.
        # It then calls the BaaS provider to create the underlying banking infrastructure.
        acc_id, iban = self.baas.create_sub_account(self.name, driver_name)
        print(f"    -> Driver Wallet Created. IBAN: {iban}")
        
        # The App can now issue a physical debit card (via a separate BaaS card issuing API).
        return acc_id

    def pay_driver_payout(self, account_id, amount):
        # The app initiates a payment. The money moves via the BaaS ACH/ISO 20022 rails.
        success = self.baas.credit_account(account_id, amount)
        if success:
            print(f"    -> ${amount} deposited into Driver's sub-account.")

# --- STEP 3: THE SIMULATION EXECUTION ---
baas_core = BaaSLedger()
uber = FinTechMarketplace(baas_core)

print("--- BAAAS SIMULATION: ONBOARDING A DRIVER ---")
driver_acc = uber.onboard_driver("Sarah Smith")

print("\n--- BAAAS SIMULATION: PAYING THE DRIVER ---")
# Sarah completed a ride. Uber uses the BaaS API to deposit $50.
uber.pay_driver_payout(driver_acc, 50.00)

print("\n--- BAAS SIMULATION: CHECKING THE LEDGER ---")
final_balance = baas_core.get_balance(driver_acc)
print(f"Sarah's Wallet Balance: ${final_balance}")
print(f"Total BaaS Transaction Ledger Logs: {len(baas_core.transactions)} entries")

Interpretation: This simulation shows the magic of Embedded Finance. The BaaS provider (the ledger) handles all the heavy lifting of holding funds and generating IBANs. The FinTech app (Uber) simply calls a JSON API. The user, Sarah, sees a “Uber Wallet” on her phone with a $50 balance. She has no idea that behind the scenes, the BaaS provider is routing the money through a chartered bank’s infrastructure, and the ledger runs entirely on a backend API.

8. SUMMARY FOR THE FINANCE PRACTITIONER

Open Banking and BaaS are the two massive architectural shifts happening in financial services today.

PSD2 is the legal hammer: It forced the legacy banks to build APIs, killing the dangerous era of “screen scraping.” As a FinTech engineer, you must now design your apps to consume these standardized REST APIs using the OAuth 2.0 Authorization Code flow with SCA (Strong Customer Authentication) requirements.
BaaS allows you to “Become a Bank” in a week: If you are building a market disruption app (like a payment app for B2B freelancers, or a crypto-on-ramp wallet), you do not need a banking charter. You integrate with a BaaS provider’s API. They give you the cards, the IBANs, and the ledger. You simply build the user interface and the KYC compliance layer.
Compliance is never outsourced: Even if you use BaaS, the liability for AML (Anti-Money Laundering) rests with your FinTech app. Your app must capture the user’s identity (KYC) and pass it to the BaaS provider before the account is created.

Diploma in Financial Technology LESSON 2: Open Banking (PSD2), Account Information Services (AIS), Payment Initiation Services (PIS), and Banking as a Service (BaaS)

Diploma in Financial Technology