A financial business can launch a polished customer app and still wait weeks to change a fee, add an account type, or connect a new payment provider. It owns the interface, but not necessarily the product beneath it.
That distinction is becoming more important as accounts, wallets, payments, payouts, cards, and stored value move into the digital products people already use. The real shift is not simply from banks to fintech companies. Banks are part of it too. Financial infrastructure is moving from closed, monolithic, vendor-controlled systems towards modular platforms that organisations can configure, integrate, and control.
The strategic question is therefore no longer just what financial product should we launch? It is also:
Who controls the transaction and accounting layer that determines what the product can do?
Finance is becoming part of the product experience
Financial functionality increasingly appears where the underlying commercial activity already happens:
- marketplaces hold merchant balances and manage settlement and payouts;
- mobility apps combine payments, stored value, and driver earnings;
- payroll platforms add cards or earned-wage access;
- telecom operators run mobile wallets;
- ecommerce platforms return refunds to in-app balances;
- digital banks and fintechs combine accounts, cards, transfers, and currency exchange in one application.
The commercial opportunity is significant. Grand View Research valued the global embedded finance market at $83.32 billion in 2023 and projected it to reach $588.49 billion by 2030, a forecast CAGR of 32.8%. These are market-value estimates, not payment volume or guaranteed provider revenue, but they illustrate the growing demand for financial capabilities inside non-traditional customer journeys.
The interface is the visible part. The constraints usually appear underneath it.
When a business wants to introduce a new fee model, product variant, payment rail, or account type, it discovers where control really sits. If the change depends on a vendor release, a long support queue, or a new custom-development project, the company may own the customer relationship while someone else’s infrastructure defines the product.
What is actually shifting?
The familiar story is that agile fintech companies are replacing slow banks. The more useful explanation is architectural. Six changes are happening across banks, fintechs, payment providers, and enterprises:
- Monolithic systems are giving way to modular components. Accounts, transaction processing, ledger, payments, reporting, and customer channels no longer have to live in one tightly coupled application.
- Closed stacks are becoming integration-oriented. Organisations can connect specialist providers for identity, cards, payment rails, fraud prevention, liquidity, and other services.
- Vendor-defined products are becoming more configurable. Product teams increasingly expect to control fees, limits, workflows, and transaction rules.
- Fragmented operations are moving towards orchestration. A shared transaction layer can coordinate providers and maintain consistent financial records.
- Modernisation is moving below the interface. A new mobile app cannot compensate indefinitely for an inflexible core.
- Infrastructure ownership is becoming a business decision. Architecture affects time to market, operating cost, product differentiation, and the ability to change providers.
The legacy problem is measurable. The Federal Reserve Bank of Kansas City reports that many US financial institutions still use core systems up to 40 years old, often running on mainframes and outdated programming languages. It identifies three practical modernisation paths:
- full core replacement;
- component-by-component replacement;
- wrapping or augmenting the legacy core with a parallel modern platform.
The first option can take several years and cost millions or even hundreds of millions of dollars, depending on institutional size and complexity. That helps explain why modular and parallel-core strategies are gaining attention: they allow an organisation to modernise selected capabilities without turning every change into a full core conversion.
Cloud adoption tells a similar story. The same Federal Reserve briefing cites research showing that more than 90% of surveyed retail banks had used cloud technology in some capacity, while adoption for integral services such as core banking remained much lower. Institutions are modernising, but critical infrastructure moves more slowly than customer-facing channels.
Owning the interface is not the same as owning the product
A modern frontend can sit on fragmented or inflexible infrastructure for years. The gaps usually become visible when the product needs to scale or change.
Common warning signs include:
- new products depend on a vendor’s release schedule;
- transaction records are duplicated across several systems;
- reconciliation requires spreadsheets or manual investigation;
- fees and limits are configured in different places;
- replacing a provider requires changes deep inside product logic;
- operations teams cannot see the full transaction lifecycle;
- expansion into another market requires rebuilding existing workflows;
- reporting depends on stitching together exports from multiple tools.
Not every organisation experiences all of these problems. But they share the same underlying issue: the customer-facing layer can change faster than the transaction and accounting infrastructure beneath it.
Why the transaction layer has become strategic
The transaction layer applies the rules of the financial product. Depending on the use case, it may control:
- customer, business, and merchant accounts;
- balances in fiat currencies, digital assets, points, or other units of value;
- transfers, payments, payouts, refunds, and currency exchange;
- transaction states from initiation to settlement;
- fees, commissions, and limits;
- contracts and product-specific rules;
- merchant operations;
- roles and permissions;
- settlement and reconciliation;
- transaction monitoring and reporting;
- integrations with banks, card processors, payment rails, KYC/KYB tools, liquidity partners, and other providers.
The accounting layer has a related but distinct job. A transaction engine decides what should happen; a general ledger records what happened financially through balanced, auditable journal entries.
Together, these layers affect four executive-level outcomes:
- Speed: how quickly the organisation can introduce a product or change its rules.
- Differentiation: whether teams can build distinct account structures, pricing, limits, and workflows.
- Operational control: whether transactions, balances, settlement, and reconciliation can be traced consistently.
- Independence: whether a provider or integration can be changed without rebuilding the financial product.
APIs solved access, not infrastructure coherence
Specialist providers have made many financial capabilities available through APIs. That lowers the barrier to launching products: a company can integrate identity verification, card processing, payment rails, local payment methods, fraud tools, banking partnerships, or liquidity rather than building them all internally.
But a collection of APIs is not yet a financial platform.
Each provider may represent accounts, balances, fees, transaction states, and events differently. Point-to-point integrations can therefore produce capable individual features but no consistent product logic or authoritative financial record.
A coherent platform needs to answer questions such as:
- Where is the source of truth for every balance?
- Which system applies fees and limits?
- How are provider events translated into internal transactions?
- What happens when a transaction fails halfway through its lifecycle?
- How are external statements reconciled with internal records?
- Can one provider be replaced without changing customer-facing product logic?
This is why orchestration matters. The role of the central transaction layer is not to replace every specialist. It is to control how those specialists work together inside the product.
A perspective shaped by more than two decades in fintech
Alex Malyshev, CEO of SDK.finance, describes the shift through more than 20 years of practical experience building and launching fintech products, including products created before SDK.finance:
“Over more than two decades of building and launching fintech products, we have seen that the biggest constraint is rarely the product idea itself. The real constraint is the infrastructure beneath it. When every new account type, fee model, integration, or customer journey depends on a rigid core or an external vendor’s roadmap, technology starts defining the boundaries of the business. Financial institutions need an architecture that lets them move faster today without giving up control of what they may need to build tomorrow.”
Alex Malyshev, CEO of SDK.finance
Five infrastructure operating models
Control is not binary. The framework below helps organisations identify their current operating model. It is a practical guide, not a universal industry standard.
| Model | What it looks like | Main advantage | Main constraint |
|---|---|---|---|
| Outsourced | One external provider controls most product logic and operational changes | Fast launch and limited internal engineering | Differentiation and roadmap depend heavily on the provider |
| Fragmented | Multiple specialist systems operate with separate records and workflows | Best-of-breed capabilities can be added quickly | Reconciliation, reporting, and product logic become dispersed |
| Integrated | Systems exchange data through APIs | Fewer manual handoffs and faster operations | Point-to-point integrations may still lack one source of truth |
| Orchestrated | A central layer coordinates accounts, rules, transactions, records, and providers | Consistent product logic and financial operations | Requires deliberate platform architecture and governance |
| Controlled | The organisation controls the strategically important configuration, data, deployment, integrations, and source code where required | Greater product freedom and long-term flexibility | Requires stronger engineering and operational ownership |
The final model is not automatically the best one. A pilot or peripheral financial feature may work well with an outsourced service. A payment company whose transaction logic is its core business may require much deeper control.
The goal is not maximum ownership. It is the right degree of control for the product’s strategic importance.
What should remain under your control?
The answer usually falls into three groups.
Product-defining capabilities
These may warrant strategic control because they shape the customer proposition and economics:
- accounts and product configuration;
- transaction rules;
- fees and limits;
- financial records and access to transaction data;
- operational roles and permissions;
- integration architecture;
- deployment model;
- the ability to replace providers.
Specialist capabilities
These are often better integrated from established providers:
- KYC/KYB verification;
- AML and fraud tools;
- card issuing and processing;
- payment rails and local payment methods;
- acquiring;
- custody and liquidity;
- notifications and communications.
Regulated responsibilities
These depend on jurisdiction, licence, and operating model:
- licensing;
- safeguarding;
- regulatory reporting;
- compliance responsibility;
- access to clearing systems;
- custody arrangements.
Software does not erase these distinctions. Owning the platform is not the same as holding a financial licence, and orchestrating a service does not make the platform operator its regulated provider.
Build, SaaS, source code, or hybrid?
Once an organisation knows what it needs to control, it can choose the delivery model.
| Dimension | Internal build | SaaS platform | Source-code licence | Hybrid |
|---|---|---|---|---|
| Launch speed | Usually slowest | Usually fastest | Moderate | Varies by component |
| Initial investment | Highest | Lower | Moderate to high | Moderate |
| Customisation potential | High, constrained by resources | Limited by platform options | High within the licensed architecture | High in selected layers |
| Engineering ownership | Very high | Low | High | Shared |
| Deployment control | High | Usually vendor-managed | High | Mixed |
| Platform dependency | Lower, with external dependencies remaining | Higher | Reduced at the licensed layer | Deliberately distributed |
| Best fit | Infrastructure is itself a differentiator | Speed and lower operational burden matter most | Deep customisation and long-term control are strategic | Different layers require different levels of ownership |
There is no universal winner. Many businesses start with SaaS to validate a proposition, then adopt deeper configuration or source-code control as the product becomes more complex and strategically important.
Where SDK.finance fits
SDK.finance provides a modular transaction and accounting foundation for banks, fintechs, payment providers, EMIs, and enterprises building ledger-based financial products.
The platform brings together:
- accounts and balances;
- payments, transfers, and payouts;
- configurable fees and limits;
- contracts and product rules;
- merchant and back-office operations;
- roles and permissions;
- transaction monitoring;
- settlement and reconciliation;
- a real-time double-entry general ledger;
- integrations with specialised and regulated providers.
Its role is not to replace every participant in the financial ecosystem. It provides the coherent layer through which those participants can be connected and operated as one product.
Infrastructure at production scale
Current SDK.finance platform figures include:
- 650+ APIs for product development and integrations;
- processing capacity starting from 2,700+ transactions per second;
- more than 34.5 million transactions per day at that throughput;
- SaaS and source-code licensing models;
- on-premise and cloud deployment options;
- PCI DSS Level 1 Service Provider and ISO 27001:2022 certifications.
The platform separates transaction processing from accounting. The SDK.finance Transaction Platform applies product and operational logic, while the real-time General Ledger turns financial events into balanced journal entries and maintains their auditable history.
What infrastructure control looks like in practice
SDK.finance customer projects show that the same foundation can support different transformation paths:
- Geidea: SDK.finance software was integrated into an existing POS network to transform transaction settlement operations. According to the published case study, Geidea serves more than 530,000 merchants and expanded the implementation across three countries.
- Nebeus: a ledger-based platform supported crypto-to-fiat connectivity and multi-currency financial operations. SDK.finance reports more than 42,000 monthly active users and over €350 million in processed transactions for the customer; the Nebeus case study explains the underlying implementation.
- Super app: another implementation supports digital payments within an ecosystem of more than 6 million users, including over 130,000 drivers and merchants, according to the SDK.finance super-app case study.
These are different products and markets. The common requirement is a transaction and accounting layer that can be integrated into the customer’s operating model rather than forcing every business into the same product structure.
Questions to ask before choosing a platform
An infrastructure assessment can start with ten practical questions:
- Can we introduce a new account or product type without redesigning the stack?
- Can product teams change fees, limits, and transaction rules without waiting for a major vendor release?
- Where is the authoritative record for every balance and transaction?
- How much reconciliation still depends on spreadsheets or manual investigation?
- Can we replace an integration without rebuilding customer-facing logic?
- Can operations teams trace a transaction from initiation to final settlement?
- Who controls deployment, data access, and the upgrade roadmap?
- Can the platform support another product, business segment, or geography?
- Which dependencies are technical, contractual, operational, or regulatory?
- Are we gaining short-term convenience at the cost of long-term product flexibility?
Control does not mean building everything
The financial infrastructure shift is not a transfer of finance from banks to fintech companies. It is a change in how banks, fintechs, payment providers, and enterprises build and control financial products.
Customer interfaces are becoming easier to reproduce. The harder and more strategic questions sit underneath them:
- Who controls the product logic?
- Where do the financial records live?
- How are providers connected?
- How expensive is the next change?
- Can the architecture evolve without replacing the entire product?
Control does not require building every component internally. It requires deliberate ownership of the layers that define the product, combined with the freedom to integrate specialist providers where they add the most value.
If your existing infrastructure is limiting the products you can launch or the providers you can change, explore the SDK.finance platform as a configurable transaction and accounting foundation.
Create your digital banking solution in weeks
Talk to Our Team
