Chapter 28: Exercises — RegTech APIs, Open Finance, and Interoperability

Exercise 1: Map the OAuth 2.0 Authorization Code Flow

Objective: Understand the sequence of steps in the Open Banking consent flow and identify the compliance significance of each step.

Scenario: Priya, a customer of Verdant Bank, wants to connect her Verdant current account to a budgeting app called SpendWise. SpendWise is FCA-authorized as an AISP. She opens SpendWise on her phone and clicks "Connect your bank account."

Task: Draw or describe in writing the full sequence of steps in the OAuth 2.0 Authorization Code Flow for this scenario. For each step, identify:

  1. Who or what initiates the action (Priya, SpendWise's server, Verdant's authorization server, Verdant's API)
  2. What data or credential is transmitted in that step
  3. The compliance significance of that step (e.g., why is this step important for consent validity? For data security? For audit trail purposes?)

Your sequence should include all of the following elements, in the correct order:

  • SpendWise constructs an authorization request
  • Priya is redirected to Verdant's login page
  • Priya authenticates using strong customer authentication (SCA)
  • Verdant presents a consent screen to Priya
  • Priya grants consent
  • Verdant issues an authorization code
  • SpendWise exchanges the authorization code for an access token and refresh token
  • SpendWise calls Verdant's API using the access token
  • The access token expires; SpendWise uses the refresh token

Written response: Approximately 400-600 words, or a clearly labelled diagram with written annotations.

Exercise 2: Identify GDPR Obligations for a TPP Receiving Customer Data

Objective: Apply GDPR principles to the Open Banking data-sharing relationship from the TPP's perspective.

Scenario: BudgetRight Ltd is FCA-authorized as an AISP. It has 95,000 active users who have connected their bank accounts to BudgetRight. Each day, BudgetRight calls the APIs of fourteen different UK banks to retrieve transaction data for its users. BudgetRight stores each user's transaction history for the duration of their active subscription, plus twelve months after they cancel (for "service continuity purposes"). BudgetRight shares anonymized, aggregated spending pattern data with a market research firm that pays BudgetRight for this data. Individual-level transaction data is also used to develop BudgetRight's internal credit scoring model, which it plans to use for a new "SmartCredit" lending product.

Task: Analyse BudgetRight's GDPR compliance by answering the following questions:

  1. In the GDPR data controller/processor analysis, is BudgetRight a data controller or a data processor in relation to the customer transaction data it receives from banks? Justify your answer.

  2. BudgetRight stores individual transaction data for twelve months after subscription cancellation "for service continuity purposes." What GDPR principles are engaged by this practice, and is the stated purpose a sufficient lawful basis for retention?

  3. BudgetRight shares anonymized, aggregated data with a market research firm. What GDPR considerations apply to this sharing, even if the data is described as anonymized?

  4. BudgetRight plans to use individual-level transaction data to develop a credit scoring model for its new SmartCredit product. Customers consented to share their transaction data "for budgeting and spending analysis purposes." What GDPR issues does this new use raise, and what would BudgetRight need to do to address them?

  5. A BudgetRight user submits a Subject Access Request. What data is BudgetRight obligated to provide, and within what timeframe?

Written response: Approximately 600-800 words.

Objective: Translate the compliance requirement for consent audit trails into a practical data architecture.

Scenario: You are the RegTech lead at a mid-sized UK bank preparing for Open Banking go-live. The Compliance Director has asked you to design the schema for the consent audit trail system — the data structure that will record every consent granted, modified, and revoked, and every API call made under each consent. The system must be able to respond to:

  • GDPR Subject Access Requests (within one month): "What data about me has been shared with third parties, and when?"
  • FCA supervisory inquiries: "Show us all API access by TPP X in the period 1 January to 31 March."
  • Customer disputes: "I revoked consent on 15 June. Why did the fintech still have my data on 20 June?"
  • Internal compliance monitoring: "Which consents have been active for more than 85 days and are approaching their 90-day expiry?"

Task:

  1. Design a database schema (table names and key fields — you do not need to write SQL DDL) for a consent audit trail system. Your schema should include at minimum: - A Consents table - A ConsentStatusHistory table (tracking all status changes over the consent lifecycle) - An APIAccessLog table - A TPPRegistry table

  2. For each table, list the key fields and explain why each field is necessary for one or more of the four query scenarios above.

  3. Identify two fields that would be particularly important for detecting the scenario described in Case Study 01 (persistent API calls after consent revocation). Explain how those fields would be used in a monitoring query.

Written response: Table definitions with field lists and explanations; approximately 400-600 words.

Exercise 4: Code Exercise — Extending the OpenBankingComplianceManager

Objective: Extend the Python implementation from Chapter 28 Section 6 with a new compliance method.

Background: The OpenBankingComplianceManager class in Section 6 manages consents, logs API calls, and generates audit trails and TPP activity reports. It does not currently support bulk revocation — a function that is needed when a TPP's FCA authorization is revoked and Verdant must immediately revoke all active consents associated with that TPP.

Task: Implement the following method on the OpenBankingComplianceManager class:

def revoke_all_consents(
    self,
    tpp_id: str,
    reason: str
) -> dict:
    """
    Revoke all active consents for a specified TPP.

    Used when a TPP's regulatory authorization is withdrawn.

    Args:
        tpp_id: The identifier of the TPP whose consents should be revoked.
        reason: The reason for bulk revocation (e.g., "TPP authorization withdrawn").

    Returns:
        A summary dict with:
            - tpp_id: str
            - tpp_name: str
            - reason: str
            - consents_revoked: int
            - consents_already_inactive: int
            - revocation_timestamp: str (ISO format)
            - affected_customers: list[str] — customer IDs whose consents were revoked
    """

Requirements:

  1. The method must identify all consents associated with tpp_id that are currently in AUTHORISED status (only active consents can be revoked).
  2. It must call the existing consent.revoke() method on each eligible consent.
  3. It must count consents that are already in an inactive status (REVOKED, EXPIRED, CONSUMED, AWAITING_AUTHORISATION) and report them separately.
  4. It must log each revocation action in the API access log — use a special endpoint string like "/admin/bulk-revocation" and a response code of 200.
  5. It must return the summary dictionary described above.

Write the complete method implementation and write a demonstration showing: - A TPP with three consents: two authorised, one already expired - Calling revoke_all_consents on that TPP - Printing the summary output - Verifying that subsequent API requests from the revoked TPP's consents are denied

Exercise 5: Is It Outsourcing? Applying the EBA Guidelines

Objective: Apply the EBA Guidelines on Outsourcing (EBA/GL/2019/02) to API-based third-party relationships.

Background: The EBA's outsourcing guidelines define "outsourcing" as an arrangement of any form between an institution and a service provider by which that service provider performs a process, a service, or an activity that would otherwise be undertaken by the institution itself. Under these guidelines, critical or important functions have heightened requirements including written outsourcing agreements, regulator notification, and exit strategies.

Task: For each of the three following API-based arrangements, determine whether the arrangement constitutes outsourcing under the EBA Guidelines, and if so, whether it is likely to be classified as involving a critical or important function. Justify your conclusion.

Arrangement A: RegulatorLink is a third-party service that provides a real-time API connection to the FCA's Financial Services Register. Cornerstone Bank uses this API to verify TPP authorizations in real time on every Open Banking API call. The RegulatorLink API is called approximately 50,000 times per day. If RegulatorLink's API were unavailable, Cornerstone could fall back to checking the FCA register website manually, though this would only support a fraction of the volume.

Arrangement B: Verdant Bank uses Fenergo, a third-party vendor, to run its customer onboarding and KYC platform. Fenergo is hosted in a cloud environment managed by Fenergo. Verdant's internal systems call Fenergo's API to retrieve KYC status for customers during product applications and account reviews. Verdant has no KYC infrastructure of its own independent of Fenergo.

Arrangement C: Cornerstone's compliance team uses a large language model (LLM) API, provided by a major AI company, to assist with drafting suspicious activity report narratives. A compliance analyst reviews and approves all AI-assisted narratives before submission. The AI produces a draft; the human decides whether to use, modify, or discard it. If the AI API were unavailable, analysts would write SAR narratives entirely manually — slower, but fully functional.

For each arrangement, address:

  1. Does this arrangement meet the EBA definition of outsourcing? Why or why not?
  2. If it is outsourcing, is it likely to be classified as involving a critical or important function?
  3. What obligations would apply to Cornerstone/Verdant under the EBA Guidelines for this arrangement?
  4. What would you recommend the firm do to bring the arrangement into compliance (if it is not already)?

Written response: Approximately 200-300 words per arrangement.