Banking as a Platform

Capabilities exposed for partners, ecosystems and internal reuse

Treat capabilities as reusable services

Banking as a Platform exposes defined banking capabilities for internal channels or external consumers. An account-information service, payment instruction or product decision can serve several applications when its interface, meaning and controls are clear. Not every platform must be open to external firms.

A platform capability needs an owner, supported use cases and operational evidence. Publishing APIs alone does not establish a complete platform or confer regulatory permissions on consumers. Distinguish the technical service from the underlying financial activity and entity.

Define the product contract

Specify inputs, outputs, statuses, errors and reference behaviour. Consumers should understand the difference between accepted, rejected, pending and completed. A response time promise should refer to the relevant service; technical availability is not the same as a completed customer payment.

Version meaningful changes and provide migration guidance. Shared capabilities can reduce duplication but also widen the effect of a defective change. Test representative consumers and important exception paths rather than assuming all implementations respond identically.

Access and financial authority

Authenticate the consumer and enforce its permitted resources, actions and limits. A known client identity does not grant authority for every customer account. Where customer permission is relevant, validate its applicable scope and status; other lawful processing bases and permissions need their own controls.

Authorisation should operate where the financial effect is enforced. An app hiding a button is insufficient if the API still accepts the action. Changes in mandates, restrictions and client permissions need controlled propagation and effective decisions, with uncertainty handled under the approved service design.

Reliable effects and evidence

Use idempotency and durable references appropriate to the operation. Different internal systems can retain distinct identifiers if mappings preserve traceability. Detect duplicates, enquire after timeouts and reconcile important financial states.

Event-driven and synchronous designs can coexist. Do not require every consumer to subscribe to every event or claim that one delivery guarantee makes an entire distributed financial process exactly once. Record version, relevant inputs, decisions and effects so authorised staff can explain outcomes.

Operations and commercial support

Provide documentation, realistic test environments, admission controls and support for actual use. Development sandboxes do not grant live financial permissions. Rate limits and capacity plans should account for critical service needs and common dependencies.

Costs can include integration, retained operations, assurance and exit alongside platform charges. The Basel third-party-risk principles provide a bank-risk reference for relevant external relationships; actual obligations and local implementation matter.

Fictional example: payment API timeout

Two channels use one payment capability. A request times out after acceptance. The retry carries the original idempotency reference, and the service checks the first request rather than generating another payment. A later status update is joined to the same business instruction.

Support can explain the instruction across channel and processor records. The platform is useful because the shared behaviour preserves financial meaning, not simply because two apps call the same URL.

Takeaway

A banking platform combines reusable interfaces with controlled authority, reliable financial effects and service ownership. Its boundaries should support both ordinary use and failure recovery.

Continue to Banking as a Service.