Open Banking and APIs for Fintech: How and Why to Open Up Access

What open banking really is — and why it's more than "giving API access"

Open banking is a model in which a bank or financial institution exposes account data and payment functions through programmatic interfaces (APIs) to trusted third-party services. The key phrase here is with the customer's consent. The user decides which app may see their account balance, transaction history, or initiate a payment on their behalf.

In practice this means three things. Technically, it's a REST or GraphQL API with clear documentation and predictable behavior. Legally, it's about consents, contracts, and how liability is split between the bank and the third party. And operationally — which is often underestimated — it's an ongoing load: SLAs, monitoring, partner support, and versioning. Opening an API is not a one-off project; it's a product with a lifecycle.

Standards: what to build on so you don't reinvent the wheel

Globally, a few reference points have emerged. Europe's PSD2 and the Berlin Group's NextGenPSD2 standard set the baseline logic: splitting roles into AISP (account information access) and PISP (payment initiation), plus mandatory Strong Customer Authentication (SCA). The UK Open Banking Standard went further in API detail. In the US and several markets, the Financial-grade API (FAPI) profile from the OpenID Foundation is popular — a hardened profile on top of OAuth 2.0 and OpenID Connect, built specifically for financial data.

In Uzbekistan there is, as yet, no single mandatory open banking standard at the regulator level in the form it takes in the EU. So in practice, teams take a proven international base and adapt it to local realities — integration with the national Uzcard and Humo payment systems, the Central Bank's information security requirements, and the established interbank exchange formats.

Security: where open banking breaks most often

An open API increases the attack surface by definition. So here, security is not "a feature at the end of the sprint" — it's the architectural foundation. The minimum mandatory set looks like this:

• Strong authentication (SCA) — two factors out of three categories: knowledge (PIN), possession (phone, token), inherence (biometrics). Payment initiation without it is unacceptable.
• OAuth 2.0 with short-lived tokens and scopes — an app gets access to exactly the data the customer consented to, and no more.
• mTLS (mutual TLS) — the bank and the third party authenticate each other with certificates, not just an API key.
• Message signing — critical requests (especially payments) are signed to rule out tampering in transit.
• Rate limiting and anomaly monitoring — protection against brute force, token leakage, and suspicious patterns.

Scenarios: what actually delivers value

Opening an API just to feel "modern" is a path to a dead integration nobody uses. The viable scenarios in our market usually look like this:

• Payment initiation for marketplaces and services — the customer pays directly from their account, without extra acquiring fees and redirects. For online commerce, that's lower costs.
• Account aggregation — a fintech app shows balances and transactions from several banks in one interface. The basis for PFM (personal finance management) services and SME bookkeeping.
• Scoring and lending — with the customer's consent, a service analyzes transaction history to assess creditworthiness. Especially valuable for segments without a classic credit history.
• Embedded finance — a non-bank business (logistics, retail, ride-hailing) embeds payments and accounts directly in its app via a partner bank's API.
• B2B settlements and accounting automation — statement exports, bulk payment initiation, reconciliation for ERP systems.

The trend in Uzbekistan: where the market is heading

Uzbekistan's fintech market has grown noticeably in recent years: Uzcard and Humo card penetration has risen, strong mobile wallets and payment apps have appeared, and digitalization of the banking sector along the Central Bank's lines has accelerated. This is fertile ground for open banking — demand for integrations has already formed from the bottom up, from fintech teams and online businesses.

For now, many integrations are built through direct bilateral "bank-to-partner" arrangements rather than a single open standard. That works, but it scales poorly: every new partner is a separate development effort. Market logic pushes toward standardized API products, and the banks that do this earlier and more conveniently will gain an edge as a platform for the fintech ecosystem.

Where to start technically

We recommend against trying to open everything at once. The working path is iterative:

• Start with a read-only scenario (balance and history access) — it's lower-risk than payment initiation.
• Build a sandbox with test data before production — partners must be able to develop without touching real accounts.
• Bake in API versioning from day one — breaking changes in a financial API without versions mean broken partners.
• Build a developer portal with documentation, keys, and call analytics — it's part of the product, not a nice-to-have.
• Plan consent management in advance — where and how the customer grants, sees, and revokes consents.