Understanding Open Banking APIs: Definition and How They Work

At the same time, many executives still ask a fair question: what is behind this door technically, and what is the risk if we open it too quickly?

In this guide, we will walk through:

• what an open banking API actually is in practice

• how open APIs in banking are reshAPIng financial ecosystems

• how open banking APIs work end to end

• real-world open banking API examples

• core standards, security profiles, and regional frameworks (including UAE Open Finance)

• what open banking API integration takes in real life, beyond vendor slides

• the cost, trade‑offs, and how a partner like Lumitech can help. 

By the end, you will have a practical view of both the opportunity and the workload required to do open banking properly — not just “ship an API”.

What Is an Open Banking API

If we remove the jargon, open banking application programming interfaces (APIs) are a standardized, secure interface that lets a regulated financial institution share specific data or trigger financial actions when the customer clearly allows it. Instead of giving a third‑party app your username and password, you grant access via strong authentication, and the bank issues a time‑limited token.

This interface usually sits between:

• an ASPSP (Account Servicing Payment Service Provider) — typically the bank that holds the customer’s account

• an AISP (Account Information Service Provider) — the app that retrieves balances, transactions, or other financial data

• a PISP (Payment Initiation Service Provider) — the app that can initiate a payment or transfer on the customer’s behalf

Everything rests on a few principles:

• customer consent is explicit, granular, and revocable

• secure authentication is handled by the bank, not the fintech app

• data exchange is encrypted, structured, and regulated

• interoperability is possible across multiple banks because they follow similar open banking API standards. 

Compared to older “screen scraping” approaches, you no longer have a bot pretending to be the user. Instead, you have a clearly defined API to connect to banks with scopes, tokens, and traceability. When stakeholders ask “what is open banking API in one sentence?”, this is often the most honest way to explain it.

Banks with Open APIs and the Shift Toward Platform Banking

Banks with open APIs are no longer only selling products; they are selling capabilities. A fintech app can, for example:

• pull categorized transactions via a categorized transactions API to build a real‑time spending dashboard

• trigger an account‑to‑account payment via an instant payments API without touching card rails

• run affordability checks via open banking by reading regular income and obligations over several months. 

In this setup, banks evolve from closed product factories into open API for banking platforms. Instead of fighting every startup, they selectively collaborate:

• a lending platform uses transaction data for faster credit decisioning

• a payroll provider uses a bank transfer API to push salaries directly from client accounts

• a multi‑country fintech uses one open banking API gateway or aggregator to talk to dozens of institutions. 

This platform mindset is what makes open banking more than a compliance checkbox. It becomes a way to distribute services, partner with others, and let innovation happen on top of stable banking rails.

To understand why this model became so attractive, it helps to zoom out and look at the broader change in how financial services are built and delivered.

Open APIs in Banking — Why the Industry Is Moving Toward Open Ecosystems

The financial industry is moving from vertically integrated stacks to interconnected ecosystems. In that world, open APIs in banking are the connective tissue that lets data and payments flow between players safely.

Benefits for Financial Institutions

For banks, an open API for banking is not only a technical decision; it is a strategic one. Done well, it unlocks:

• Faster innovation cycles, because new features can be exposed via APIs without rebuilding whole channels

• Deeper fintech partnerships, where startups bring UX and niche use cases while banks provide balance sheets and trust

• Banking‑as‑a‑Service models, where third parties can embed accounts, cards, or lending inside their own products

• API monetization, such as premium tiers on an open banking API platform for high‑volume partners

• Better customer experience, since customers can use their bank in multiple apps instead of a single web portal. 

Banks that move early tend to set the “terms of engagement” with partners. Those who wait risk being treated as commodity pipes, interchangeable with any other institution that finally opens up.

Benefits for Customers and Businesses

Customers and business users experience open banking in very concrete ways, often without realizing that APIs sit behind it. They get:

• Unified dashboards that aggregate accounts from multiple institutions into one interface, similar to a multi-bank platform that centralizes high-yield savings customer story

• Smoother lending journeys where they share bank data once and receive decisions in minutes

• Payment processing that feels embedded, not bolted on — such as paying directly from a bank account inside an e‑commerce checkout

• Automated financial insights that flag unusual spending, remind about upcoming obligations, or optimize savings. 

Because open banking and API integration shift control from institutions to users, people can move data where it creates value. At the same time, banks that support these patterns can deepen relationships instead of losing customers to the first shiny fintech app. To see how this comes together technically, let’s walk through how open banking APIs work end to end.

How an Open Banking API Works

Even if each market has its specifics, the way of how open banking APIs work usually follows a similar flow:

1. Customer authorizes access. Inside a fintech app, the user chooses their bank and the type of access (for example, read transactions for 90 days). The app redirects the user to the bank’s secure environment.

2. Application sends API request. Once the customer is at the bank, the third‑party app is identified using client credentials. It requests the necessary scopes — such as access to balances or the ability to initiate a single payment.

3. The bank authenticates identity. The bank performs Strong Customer Authentication (password, biometrics, OTP, or a combination). This ensures the consent comes from the real account holder.

4. Secure token issued. If authentication and consent succeed, the bank issues an access token and, often, a refresh token. The third‑party never sees the login details — only these tokens.

5. API retrieves financial data or initiates actions. Using the token, the app calls the open banking API for banks to:

   • read balances and transactions

   • trigger a payment

   • check account ownership or income patterns. 

Throughout this process, security frameworks such as OAuth 2.0 and OpenID Connect govern token issuance and validation. The bank’s open banking API security profiles define which flows are allowed and under what risk policies.

Role of an Open Banking API Gateway

In production, these calls do not hit core banking systems directly. They pass through an open banking API gateway that acts as a control and observability layer. The gateway:

• enforces authentication and authorization for every incoming request

• applies traffic controls and rate limits, so a popular app does not overload the bank at peak time

• validates payloads against open banking API standards and schema definitions

• centralizes logging and API error handling in fintech, making it easier to trace issues across dozens of partners. 

In many organizations, this gateway is part of a broader open banking API platform that also includes monitoring, sandbox environments, and partner management tools. Once this infrastructure is in place, banks and fintechs can start building concrete use cases on top of it.

Open Banking API Examples

Open banking APIs already power entire categories of financial products that did not exist a decade ago.

Personal Finance Applications

Personal finance management tools use open banking APIs to pull account data from multiple institutions and present it in one view. A customer can see current accounts, savings, and even loans in a single dashboard, instead of juggling five apps.

In our own work at Lumitech, we helped design a multi-bank platform that centralizes high-yield savings for US depositors, automatically comparing FDIC and NCUA‑insured products. While that project runs under a different regulatory regime, the core pattern is similar: normalized APIs, standardized data, and clear consent flows.

If you want to see how such architecture looks in practice, it is worth exploring the full story of this project and how API‑driven aggregation supported both compliance and customer experience.

Discover More

Payment Initiation Platforms

Another major category is payment initiation. Instead of relying on card schemes, a merchant can let customers pay directly from their bank accounts. The app uses an open banking API to:

• request permission to initiate a one‑off or recurring payment

• redirect the user to their bank for approval

• receive confirmation and update the order in real time

Because this flow bypasses card rails, merchants can reduce payment processing costs and sometimes settle faster. For recurring invoices and B2B payments, having a robust open banking API gateway and instant payments API can significantly reduce friction and errors compared to traditional bank file uploads.

Lending and Credit Assessment

Lending platforms and banks use open banking API integration to enrich their credit decisioning. Instead of relying only on bureau data and static income declarations, they can:

• read transaction histories

• spot regular salary payments

• detect patterns of spending or prior defaults

This data supports faster credit decisioning while keeping human oversight where it matters. It also pairs naturally with KYC automation and data governance in banking, especially when lenders want a clear audit trail of what data influenced the decision.

These examples demonstrate that open banking is not an abstract trend. It is a foundation that supports very concrete, measurable improvements for both customers and financial institutions. Behind each of these use cases sits a multi‑layer architecture designed to keep data secure and systems robust. 

Key Components of the Open Banking Ecosystem

Open banking is more than “just an API exposed by IT”. It is an ecosystem of components that have to work together without introducing unnecessary fragility. Typical elements include:

• API gateways — policy enforcement, traffic management, routing

• Developer portals — documentation, test consoles, onboarding forms for partners

• Identity and access management — strong authentication, role‑based access, token services

• Consent management systems — storage of consents, scope, duration, and revocation

• Monitoring and fraud detection — real‑time analytics on unusual access patterns or transaction anomalies

Core Infrastructure Layers

A pragmatic architecture for an open API for banking usually follows four main layers:

1. API gateway. This is the entry point for all third‑party calls. It handles TLS, certificates, quotas, and basic validations.

2. Authentication and consent layer. This layer issues and validates tokens, enforces SCA, and records which application can access which account for how long.

3. Middleware integration layer. Often, banks have several legacy systems. Middleware translates modern REST or event‑based calls into formats that core banking understands. This is where app modernization companies usually spend a lot of effort, cleaning interfaces without rewriting the whole bank.

4. Core banking system. The system of record for balances, transactions, limits, and customer master data. Ideally, it only sees requests once they are fully authenticated and validated upstream.

On top of these layers, you will often see specialized components for risk scoring, generative AI in banking (for example, to assist support staff with complex queries), and dedicated modules to improve onboarding with bank data. To allow all of that to interoperate across institutions and borders, the industry relies heavily on shared standards.

Open Banking API Standards

Because one fintech app might connect to dozens of institutions, we need common rules for structuring data and managing security.

Global Open Banking API Standards

Several major frameworks cover open banking API standards or closely related open finance use cases:

• PSD2 in the European Union — mandates access for licensed AISPs and PISPs and defines broad security requirements

• OBIE in the United Kingdom — more prescriptive profiles for endpoints, payloads, and security profiles

• Berlin Group NextGenPSD2 — widely adopted across continental Europe for harmonized APIs

• FDX in the United States — industry‑driven standard that goes beyond pure banking into investments and insurance

These initiatives define not only endpoint structures, but also how consents are expressed, what error codes should look like, and how institutions should implement strong authentication.

UAE Open Finance Framework

In the UAE, the Central Bank’s Open Finance Framework takes things one step further by:

• Promoting a centralized API hub architecture (such as the Nebras platform) as a shared open banking API platform for banks and fintechs

• Mandating participation for licensed banks in key open finance use cases over time

• Enforcing data residency, so sensitive data stays within approved jurisdictions

• Aligning on ISO 20022 for financial messaging to keep compatibility with payment and settlement systems

• Requiring robust consent and revocation flows that are easy for customers to understand. 

For institutions in Dubai and across MENA, this is not just a regulatory challenge. It is also an opportunity to design a future‑proof integration strategy before fragmentation becomes unmanageable.

Security Protocols Behind Open Banking APIs

On the security side, most implementations rely on:

• OAuth 2.0 and OpenID Connect for token‑based access and federated identity

• Strong Customer Authentication (SCA) to meet regulatory expectations and prevent unauthorized access

• Mutual TLS (mTLS) to ensure both client and server prove their identity

• FAPI (Financial‑grade API) profiles, which harden OAuth and OIDC for financial use cases. 

Together, these frameworks ensure that even if you expose a broad set of capabilities via APIs, you still control precisely who can do what, when, and under which risk settings.

With standards in place, banks face the practical question: how do we actually integrate this into our existing landscape?

Step-by-Step Open Banking API Integration Process

Implementing open banking is not a “weekend project”. It touches architecture, compliance, operations, and the developer ecosystem. A realistic open banking API integration program often follows these steps:

1. Regulatory compliance assessment. Map which services fall under open banking or open finance rules in your jurisdictions and what licenses (AISP, PISP, etc.) are in play.

2. API architecture design. Decide which services will be exposed, under which open banking API standards, and how they align with existing channel APIs.

3. Gateway deployment. Roll out or extend an open banking API gateway that supports mTLS, OAuth, and FAPI.

4. Legacy system integration. Implement adapters in the middleware layer so that core systems can be accessed via the new interfaces without fragile point‑to‑point connections. This is where cooperation with specialist vendors or IT infrastructure companies in Dubai and similar markets can be helpful.

5. Authentication framework implementation. Integrate SCA mechanisms, token services, and consent storage, ensuring alignment with your broader data governance in banking policies.

6. Testing and regulatory validation. Run functional, performance, penetration, and compliance tests. Engage regulators or central hubs where sandbox testing is required.

7. Developer portal launch. Publish documentation, SDKs, test credentials, and onboarding flows for fintech partners and internal teams.

Even with such a structured plan, banks typically encounter challenges that are more organizational than purely technical.

Challenges Banks Face When Implementing Open Banking APIs

Banks often go into open banking thinking it’s “just another integration project”. In reality, it is closer to rewiring your digital backbone while the bank is fully live. Here are the main challenges, the risks behind them, and what it realistically takes to mitigate them.

Legacy Infrastructure Limitations

Your existing core and satellite systems are not designed for real‑time, high‑volume API traffic, so you end up with brittle integrations, timeouts, and outages just when a new fintech partner starts sending real customers your way. If performance and reliability are poor, partners will quietly route traffic to other institutions, and regulators will start asking uncomfortable questions about operational resilience. 

To solve this challenge, it is necessary to introduce a robust middleware layer, decouple external APIs from the core with caching and asynchronous patterns, and gradually modernize critical systems in collaboration with experienced app modernization companies instead of trying a “big bang” rewrite.

Regulatory Fragmentation

Different jurisdictions and product lines fall under different interpretations of open banking and open finance, so a single architectural decision can unintentionally put you out of compliance in one market while solving a problem in another. Non‑compliance in this domain is not just about fines; it can also slow down product launches, block partnerships, or require costly rework of consent flows and data sharing logic.

That’s why you have to design your open banking API platform around configurable policy engines and region‑specific profiles, and keep a joint working group between legal, compliance, and architecture that reviews every new use case before it hits production.

Security and Fraud Prevention

Opening APIs increases your attack surface, so weak token management, poor open banking API security profiles, or rushed onboarding of third parties can result in data leakage, fraudulent payments, or abuse of your infrastructure. A single incident erodes customer trust, invites regulatory scrutiny, and can derail your entire open banking roadmap for years while you deal with remediation.

To prevent and avoid this risk, implement financial‑grade OAuth/FAPI, mTLS, continuous monitoring, and fraud analytics from day one, and treat new API consumers as you would a new correspondent bank — with careful vetting and ongoing oversight.

Scaling API Traffic

The nature of this risk is as follows. You design for “pilot volumes”, then a partner app goes viral and suddenly your open banking API gateway and back‑end services cannot handle the load, causing cascading failures across channels. In an API ecosystem, one overloaded node can degrade the experience of every connected partner and end customer, not just the “noisy” one.

So, size your infrastructure for peak scenarios, add rate limiting and back‑pressure mechanisms at the gateway, and work with reliable IT infrastructure companies in Dubai or similar operations partners to test realistic traffic patterns before launch.

Organizational Transformation

Business, IT, risk, and legal each have their own view of open banking, leading to misaligned priorities, slow approvals, and APIs that technically exist but are almost impossible for partners to use. Without internal alignment, you end up with “checkbox” compliance — you have APIs, but no ecosystem, no adoption, and no clear ROI.

That’s why you have to treat open banking as a cross‑functional program with a clear product owner, shared KPIs, and joint decision‑making, rather than as a series of isolated IT or compliance tasks.

Data Governance and Quality

If your underlying data is inconsistent across systems, poorly categorized, or not governed, even the best‑designed APIs will return noisy, confusing, or outright incorrect results. Partners rely on your data to improve onboarding with bank data, run affordability checks via open banking, or power downstream analytics — if they cannot trust it, they will either leave or build costly workarounds.

Invest early into data governance in banking, including clear ownership of domains, standardized schemas, and data quality monitoring, so that API consumers see your institution as a reliable source of truth.

When you treat these challenges as risks to be managed, not as surprises to react to, you can plan budgets, timelines, and mitigations realistically — and avoid the “we thought it was a small pilot” trap.

Open Banking API Providers and Platforms

Institutions rarely build everything from scratch. They mix and match aggregators, infrastructure platforms, and internal components.

Open Banking API Providers and Aggregators

Aggregators connect to multiple institutions and offer a single API to connect to banks. Typical players include:

• Plaid — a financial data aggregation layer with focus on North America and Europe

• TrueLayer — offering both data aggregation and payment initiation services.

These open banking API providers reduce the integration burden for fintech companies. Instead of connecting separately to fifty banks, a startup can onboard once and expand coverage as the aggregator grows.

API Infrastructure Platforms

On the infrastructure side, platforms like Tyk or Kong provide tooling to run a high‑throughput, secure open banking API platform:

• Tyk — lightweight, developer‑friendly gateway with flexible deployment models

• Kong — enterprise‑grade API management with a strong plugin ecosystem.

They do not provide financial data themselves, but they help banks expose and govern APIs at scale, including open banking API security profiles and complex routing logic.

Even with good tools, banks still need to decide what to own and what to outsource.

Build vs. Buy — Choosing the Right Open Banking API Strategy

In practice, institutions end up somewhere on a spectrum between fully homegrown and fully outsourced open banking API development. Let’s compare the approaches 

Building internally: 

• Pros: maximum control over roadmap, architecture, and compliance posture; easier to align with internal risk standards.

• Cons: high upfront cost, need for specialized skills, longer time‑to‑market.

Using external platforms and aggregators: 

• Pros: faster launch, easier access to multiple markets, pre‑built tools for consent and monitoring.

• Cons: dependency on vendor uptime and roadmap, sometimes limited control over fine‑grained behavior.

For many, a hybrid approach works best: core risk and consent engines are built internally, while connectivity to foreign banks or niche services goes through external aggregators. This pattern is similar to how institutions approach other complex domains such as mobile banking app development in the UAE, where it rarely makes sense to reinvent every wheel.

Regardless of the mix, the quality of your implementation partner will heavily influence outcomes.

Key Considerations When Choosing an Open Banking API Implementation Partner

Selecting a partner here is not like buying a one‑off SaaS tool. You are effectively inviting someone into the core of your digital banking architecture. Criteria to look at:

• Regulatory compliance expertise — do they understand PSD2, open finance, and local frameworks like the UAE Open Finance initiative?

• Security architecture capabilities — can they design and audit systems that align with FAPI and your internal security policies?

• Legacy integration experience — have they dealt with mainframes, proprietary cores, or complex card systems before?

• API performance and scalability — can they demonstrate experience with high‑throughput, low‑latency APIs?

• Developer ecosystem support — documentation quality, sandbox design, and ongoing support for fintech partners

• Long‑term innovation potential — are they exploring areas like generative AI in banking for developer support, anomaly detection, or smarter monitoring? 

Total Cost of Ownership of Open Banking API Implementation

Talking about “cost to implement open banking” only in terms of initial build is misleading. What you really sign up for is a multi‑year total cost of ownership (TCO) that spans infrastructure, people, compliance, and ecosystem support. Let’s unpack each cost driver and how it actually behaves over time.

Infrastructure

What it includes:

• API gateways (licensing, clustering, HA setup)

• Compute and storage for token services, consent systems, fraud tools

• Logging, monitoring, and alerting stacks

• Network security, TLS termination, key management

How it affects cost:

• Upfront: Expect a noticeable initial spend on a robust open banking API and surrounding tooling, especially if you need high availability across multiple data centers or regions.

• Ongoing: As transaction volumes grow or you launch new services (for example, instant payments API or a high‑traffic bank transfer API), infrastructure cost scales with peak load and redundancy requirements, not just average traffic.

What to keep in mind: if you under‑invest here, you pay later in unplanned downtime, fire‑drill scaling, and partner churn. If you plan properly, you can optimize usage and even reduce payment processing costs by replacing batch processes with efficient APIs.

Compliance and Security

What it includes:

• Regular penetration tests, code reviews, and red‑teaming for APIs

• External audits for open banking, open finance, and data protection

• Implementing and maintaining open banking API security profiles, SCA, and consent flows

• Adapting to regulatory changes (new scopes, reporting, or consent models)

How it affects cost:

• Upfront: Initial compliance work (policies, controls, documentation) can be heavy, especially if you are moving from minimal API exposure to a full ecosystem.

• Ongoing: Regulations, security threats, and standards evolve; you will spend money every year on updates, audits, and adjustments, similar to how you maintain your core KYC and AML stack or broader kyc automation.

What to keep in mind: security and compliance costs are essentially the “insurance premium” for your open banking initiative. Cutting corners here saves money short term and dramatically increases the probability of an incident that wipes out that saving.

Development and Modernization

What it includes:

• Designing and building the APIs themselves (specs, implementations, tests)

• Middleware work to shield legacy systems from direct exposure

• Modernization of specific services or data stores that cannot support open banking demands

• Introducing new microservices to handle workloads such as categorized transactions API or faster credit decisioning logic

How it affects cost:

• Upfront: This is usually the largest visible chunk — the original “project budget” for building and integrating APIs.

• Ongoing: You will continue paying for feature requests, open banking API integration with new partners, changes in open banking API standards, and internal improvements.

What to keep in mind: if your legacy systems are particularly fragile, expect a multi‑year modernization path where you progressively refactor “hot spots” rather than one massive replacement. This is where choosing partners, including app modernization companies, has a direct impact on long‑term TCO.

Ecosystem and Partner Support

What it includes:

• Building and maintaining a developer portal, documentation, and sample code

• Partner onboarding: due diligence, legal reviews, technical hand‑holding

• Continuous partner support for integration issues and API error handling in fintech scenarios

• Running sandboxes, test environments, and change‑management communications

How it affects cost:

• Upfront: Portal design and first batch of documentation is a one‑off, but it needs thoughtful investment if you want to be seen as a “good” bank to build on.

• Ongoing: As more partners integrate, support volume grows; expect ongoing FTEs dedicated to partner success, education, and technical troubleshooting.

What to keep in mind: a successful open banking program behaves like a small product ecosystem. The more you grow, the more you need to invest into making that ecosystem healthy. This is where working with managed partners — from IT infrastructure companies in Dubai to managed IT services in Dubai — can offload part of the operational overhead.

Internal Operating Model and People Costs

What it includes:

• Product owners for the open banking portfolio

• Architecture, security, and data governance roles

• DevOps and SRE staff to keep the platform reliable

• Training for internal teams and support staff on how to handle API‑driven cases

How it affects cost:

• Upfront: You may need to create or upgrade roles that did not exist before (API product owner, ecosystem manager, etc.).

• Ongoing: Salaries and training become part of your fixed cost base; as the platform becomes mission‑critical, you cannot simply “pause” these functions.

What to keep in mind: you are not only buying software and hardware — you are building a new operating model. The institutions that accept this early usually make better decisions about where to build capabilities internally and where to rely on external partners like Lumitech or regionally trusted IT outsourcing companies in Dubai.

How Lumitech Helps Banks and Fintechs Implement Open Banking APIs

Lumitech works with banks, lenders, and fintech companies to design and implement secure, scalable open banking API platform architectures. Our approach combines:

• Secure open banking architectures — from gateway policies to consent flows, aligned with both global and local open banking API standards

• Legacy integration — connecting APIs to existing cores and card systems without creating fragile spaghetti, often as part of broader data governance in banking initiatives

• Security frameworks — implementing OAuth 2.0, OpenID Connect, SCA, and FAPI profiles, and aligning them with KYC, AML, and kyc automation solutions

• Developer experience — building clear portals, sandbox environments, and tooling that make your institution pleasant to integrate with

• Regional expertise — including projects in markets that are actively rolling out open finance initiatives, as well as work on AI‑enabled products like logistics optimization or AI in healthcare apps. 

In addition, we help clients think beyond “compliance only” and design services that leverage open banking data to create new revenue streams:

• an analytics-driven investment platform that proposes better allocation options

• embedded lending journeys inside partner apps

• experiments where generative AI in banking supports customer support agents with context‑aware responses.

If you are planning your next phase of open banking API for banks or considering open banking and API integration as part of a larger digital transformation, we can help you map priorities, risks, and quick wins — not just build endpoints.

Request a Roadmap

Conclusion

Open banking APIs changed the financial conversation from “who owns the customer” to “who delivers the best value with the customer’s consent”. An open banking API is, in essence, a well‑governed doorway into accounts, payments, and financial histories that lets banks and fintech companies collaborate without losing control over risk and compliance.

This shift enables better banking apps, embedded finance journeys, and more nuanced credit and savings products. At the same time, it requires serious attention to security, regulation, architecture, and long‑term operations. Simply exposing a few endpoints is not enough — you need a coherent strategy, strong governance, and reliable partners.

Institutions that treat open banking as infrastructure, not a side project, will be positioned to launch new services faster, reduce payment processing costs, and respond more flexibly to customer expectations. Those who delay may find themselves locked out of ecosystems where the default expectation is simple: if I trust you with my money, I should be able to use that relationship anywhere I choose.

If you are exploring how to implement an open banking API, or looking at a broader roadmap that includes open finance, mobile banking or AI‑driven experiences, Lumitech is ready to help you design a realistic, phased plan — and execute it.

Schedule Strategy Session