Disclosure. I’m at eOS now. The only specifics here are public: we’re leading the BaaS launch in Israel with Bank Esh as the sponsor bank, and Altshuler will be the first non-bank represented through Bank Esh on our technology. Everything below describes the kind of platform problem this work is, generalized. No customer-specific detail.

The problem nobody wanted to fully name

Embedded finance, as a category, is described by its outputs. A marketplace can offer its sellers a card. A payroll product can issue accounts. A fintech can clear payments without holding a banking license. The category sells on convenience.

Inside the platform, the picture is different.

You’re being asked to build one piece of software that serves three completely different stakeholders, in two jurisdictions, with regulatory constraints that age unpredictably. The category sells convenience. The work is reconciliation.

Specifically: I work on the payments-specific module. It needs to serve a sponsor bank with a 40-year-old core, a fintech that ships weekly, and the regulator looking at both. In two countries. With AI integrated into the right places — not as a feature, as part of how the system thinks.

This is a story about how you keep that platform from collapsing into three platforms.

Stakeholder one: the bank with legacy

The sponsor bank’s core is older than I am. Its release calendar is quarterly. Its security posture is "everything denied unless explicitly allowed, written in triplicate." Its compliance team — rightly — won’t sign off on a change unless they can defend it in front of the regulator six months later.

You don’t fight that. You design around it.

The platform exposes a stable contract to the bank — a small, slow-moving surface area that maps to the bank’s actual operational cadence. Behind that contract, we ship what we want at the speed we want. The bank only sees the version we promised. Internal velocity isn’t visible to them. It isn’t visible to the regulator either, because every change is logged in the audit log they can read.

The mental model: a stable wall on the bank side, fast iteration on our side, a strict contract between the two.

Stakeholder two: the fintech with the deadline

The fintech operating on top of our platform doesn’t have a 40-year-old core. They have a roadmap that ships every Friday. They have customers who churn if onboarding takes more than a day. They want APIs that let them iterate. They want a sandbox with realistic data.

You don’t fight that either.

The same platform exposes a fast contract to the fintech — a richer, more frequently-evolved API surface. New capabilities ship to the fintech months before they ship to the bank’s slow contract, because the fintech’s risk model is different and the fintech’s regulator-facing story is different. (More precisely: the fintech’s regulator-facing story is our platform-level audit log.)

The trick: both contracts have to be derived from the same underlying capability. If we’re moving money, the bank’s slow contract and the fintech’s fast contract are two views into the same data model. Diverging them — even temporarily — is how platforms become two platforms. Once that happens, every new feature has to be built twice. Once that happens, you’re a software-services company, not a platform.

Stakeholder three: the regulator

The regulator is not a stakeholder we sell to. The regulator is the first-class user of the audit log.

Every transaction, every state change, every override has to land in a log the regulator can read on demand, with the context they need: who initiated, what tier of approval applied, what alternative was rejected, why. Not as a forensic exercise. As a continuous, queryable record.

This shapes the data model from day one. We don’t build the audit log as a downstream tax. We build the data model so the audit log falls out of it for free. Every transaction is born with the metadata it needs to defend itself in a regulator’s review three years from now. Adding that metadata later — when the regulator asks — is the most expensive engineering work I’ve ever seen.

The lesson, from people who learned it the hard way at sponsor banks that have failed: don’t treat the regulator as a quarterly disclosure. Treat them as a continuous read replica.

Two jurisdictions, one platform

Israel and the United States have different rails. RTP and FedNow versus MASAV. Different sponsor-bank shapes. Different regulator expectations. Different identity-verification primitives.

The wrong instinct is to build jurisdictional code paths — if (country === "US") { ... } else { ... }. That works for the first program. It collapses on the third.

The right instinct is to make jurisdiction a first-class field in the data model and a first-class concept in the capability layer. A ledger entry has a jurisdiction. A payment instruction has a jurisdiction. A compliance check has a jurisdiction. The capability layer reads jurisdiction the way good code reads currency — as a property of the object, not a branch in the controller.

This costs more to build at first. It buys you the ability to add a third country in months instead of years. And eventually you’ll have to.

Where AI fits

Not as a feature. As part of how the system thinks.

Three places, specifically.

The audit-log reader. Regulators read audit logs by sampling. Internal compliance teams should be able to read them by question. We’re building a layer that lets compliance ask, in plain English, show me all transactions over $X where the second-tier approval was rejected. The plain-English query routes to a structured query against the audit log, with results the human can verify. The human stays in the loop. The query gets faster.

The synthesis layer for new programs. When a new fintech wants to onboard, the synthesis layer reads their proposed program structure, compares it to existing programs we’ve already approved with the regulator, and surfaces the deltas that need new attention. Most fintechs are 80% the same as a program we’ve already shipped. The 20% is the work. AI surfaces the 20%.

The drafted change. A regulator publishes a new directive. The system reads it, drafts which capabilities are affected, and proposes the migration plan. A human reviews. A human approves. The drafting time, which used to be weeks, is hours. The approval step, which is the part that matters, stays exactly as careful as it was.

In every case, the AI proposes. A human signs. The audit log records both.

What this is, underneath

Embedded finance, in this shape, isn’t a feature. It’s a contract architecture.

Three contracts: with the bank (slow, stable), with the fintech (fast, rich), with the regulator (continuous, legible). One data model serving all three. Two jurisdictions, both first-class. AI inside the system, not bolted onto it.

When this works, none of the three stakeholders sees the platform. The bank sees a vendor that fits its quarterly cadence. The fintech sees a fast API. The regulator sees a clean audit trail.

That invisibility is the product.