// the find
OpenBankProject/OBP-API
An open source RESTful API platform for banks that supports Open Banking, XS2A, PSD2 and Open Finance through access to accounts, transactions, counterparties, payments, entitlements and metadata - plus a host of internal banking and management APIs.
OBP-API is a Scala platform that lets banks expose their core systems through a standardized REST API, supporting Berlin Group (PSD2/XS2A), UK Open Banking, Australian, Polish, and Bahrain standards simultaneously. It abstracts away core-banking connector differences so third-party apps can talk to multiple banks through one interface. The target adopter is a bank or fintech integrator, not an individual developer building a side project.
Multi-standard coverage in a single deployment is genuinely rare — running Berlin Group v1.3, UK OB v3.1, AU Open Banking, and OBP's own v1.2.1-through-v7.0.0 concurrently without forking is a real operational win for anyone bridging multiple regulatory regimes. The connector abstraction (via Akka remoting) cleanly separates JDBC access from the API tier, so the database box never needs a public port — a sensible security boundary for banking infrastructure. The frozen-API test mechanism (FrozenClassTest) that fails CI when a STABLE endpoint's request/response shape changes is a disciplined way to enforce the 'don't break consumers' contract. Active migration from Lift's synchronous model to http4s/Cats Effect is the right long-term direction and it's actually in progress, not just planned.
Lift Mapper as the ORM means schema management is opaque and painful — there's no migration history you can read and reason about, just Lift's runtime DDL. The build requires 3–6 GB of heap just to compile, which tells you something about how much accumulated weight the codebase is carrying. The AGPL + commercial license split is a real problem for the target market: any bank that wants to embed this in a proprietary product has to negotiate with TESOBE, which kills self-service adoption in exactly the sector it's aimed at. Configuration via Lift's props files (OBP_OPENID_CONNECT_ENABLED style env-var overrides aside) is awkward for cloud-native deployments — there's no clean 12-factor story and Kubernetes operators will fight the config model.