Open Banking Business Models
Aggregation, lending, payments, identity and data services
Follow the value and the payer
An open-banking business model explains the problem solved, who pays, how costs and losses arise and what authority permits the activity. API access is an input to the business, not proof that the service has useful economics or appropriate customer outcomes.
Common models include customer-paid budgeting, bank-funded aggregation, lender-paid affordability tools, merchant-paid payment initiation and infrastructure sold to other providers. A brand may combine several. Each purpose and money flow should be explicit rather than hidden behind a free app label.
The main earning patterns
| Model | Typical value | Questions to assess |
|---|---|---|
| Aggregation and insights | A joined financial view | Who funds it, how accurate is it, and what further use occurs? |
| Credit assessment or distribution | Better application information or reach | Who makes the decision, and what authority permits the data use? |
| Payment initiation | A checkout or collection capability | What is final, who handles disputes, and what are total operating costs? |
| Verification | Evidence for a defined fact or authority | What exactly does the signal prove and what does it not prove? |
| Infrastructure | Connectivity, processing and support | How are access, concentration and downstream actors controlled? |
Permission is not a revenue entitlement
Data obtained for budgeting does not inherently authorise selling leads or training a credit model. Assess the further purpose, lawful basis, recipient role and disclosures under the applicable rules. A commercial agreement between firms does not automatically expand the customer's permission.
Explain material incentives and referrals as required. A service can have legitimate multiple purposes, but the customer should not be misled about who receives information or why. Separate consent is required where the applicable framework requires it; do not invent one universal permission-screen layout.
Economics after operation
Contribution depends on revenue less relevant delivery, acquisition, support, control, fraud and recovery costs. For a checkout service, examine completion, reconciliation, dispute handling and customer assistance rather than only the cost of a card alternative. Open banking does not inherently mean zero processing cost or zero fraud.
For aggregation, recurring refresh, broken connections and data interpretation can create support costs even when access is inexpensive. For credit services, funding, losses and servicing belong to the responsible credit business; an introducer fee should not be confused with interest income or underwriting authority.
Worked example: an apparently free budgeting app
In this fictional example, an app receives revenue for introducing customers to loans. Its account-data connection helps generate spending insights, while a separate commercial feature recommends products. The operator must assess whether its data use, referral activity and customer journey are permitted and accurately explained.
A healthy model measures useful insight, understood recommendations, support outcomes and contribution after costs. High referral revenue accompanied by unexpected marketing and complaints may reveal a mismatch between customer expectations and actual use. A free price does not establish fair treatment.
Responsibility and evidence
Name the service provider, account holder, lender, merchant and relevant intermediaries. Distinguish commercial responsibility from legal liability. The payment's acceptance point does not universally assign every refund, fraud or disclosure loss to one party.
Keep correlated records for the service, authority, data used, payments and fees. Ensure support can identify the correct counterparty without sending the customer around a chain of brands. Review dependence on aggregators, banks and infrastructure against the actual customer service.
Sources and takeaways
The EBA PSD2 rulebook and Australian CDR guidance illustrate why access roles and permissible use depend on the framework.
A viable model aligns customer benefit, permitted activity, honest incentives and contribution after operational costs. Connection counts and funding valuations are insufficient evidence.
Continue to API Performance & Customer Impact.