I designed an AI decision layer for SME liquidity — the interesting part wasn't the AI

I've just finished and submitted a solution for an SME innovation challenge, and I wanted to share the engineering thinking behind it because the problem ended up being much more interesting than I initially expected.

The challenge was essentially:

How do you help SMEs make better liquidity decisions using the financial and operational data they already have?

My first instinct was NOT to build another dashboard.

Most businesses already have plenty of dashboards.

The harder problem is the decision loop:

Data exists

→ something changes

→ a liquidity opportunity/risk appears

→ someone needs to understand it

→ compare possible actions

→ apply business constraints

→ get approval

→ execute

→ measure what happened

That led me to design the system as a decision layer rather than a reporting layer.

The architecture is roughly:

ERP / Accounting / POS / Payment / Banking

↓

Connector layer

↓

Canonical data model

↓

Event / signal layer

↓

Forecasting + scenario analysis

↓

Optimization

↓

Policy / permissions

↓

Human approval / consent

↓

Execution adapters

↓

Measurement

The system is API-first and connector-driven.

The goal is that an SME shouldn't have to rip out its existing systems just to use the capability.

The connectors feed a canonical model around things like:

\- customers

\- invoices

\- obligations

\- cash

\- payment timing

\- settlement events

\- forecasts

Then the intelligence layer can reason about the situation and compare feasible actions.

But there's a boundary I was very deliberate about.

I don't think a financial system should be:

LLM → “do this” → automatically move money.

That's a pretty dangerous abstraction.

Instead, I separated intelligence from execution.

The AI/analytics layer can:

\- forecast

\- identify patterns

\- explain evidence

\- compare scenarios

\- optimize feasible actions

\- recommend a decision

But the system still enforces:

\- deterministic calculations

\- policies

\- limits

\- permissions

\- consent

\- approvals

\- audit trails

\- tenant isolation

\- idempotency

\- observability

\- retries/recovery

The prototype also deliberately does NOT autonomously move customer funds.

The idea is to keep regulated execution behind appropriate partners/infrastructure and keep the decision system consent-bound.

I found that boundary more interesting than the LLM part itself.

Because once you put an LLM inside a production workflow, the real engineering questions become:

What is the model allowed to decide?

What is it allowed to recommend?

What is it allowed to execute?

What requires deterministic verification?

What requires a human?

What happens when the model is wrong?

What happens when an external API fails halfway through?

What happens when the same event arrives twice?

What happens when the underlying financial data changes after the recommendation?

Those questions pushed the design much closer to distributed-systems engineering than “just add AI.”

For the proposed pilot, I also wanted to avoid the usual AI-product vanity metrics.

I'm not particularly interested in saying:

“We processed X million AI requests.”

The useful metrics are things like:

\- cash conversion cycle

\- days sales outstanding

\- working capital released

\- settlement time

\- manual finance effort

\- decision-to-action time

In other words:

Measure the money and operational outcome, not the amount of AI activity.

The proposed scale path was:

150+ SMEs

→ validate workflows and economics

1,000+

→ standardize connectors and policies

10,000+

→ automate onboarding and monitoring

40,000+

→ operate as a reusable digital capability

The interesting scaling mechanism isn't hiring 40,000 people to operate the system.

It's standardizing connectors, policies, workflows and automation.

That's the part I'm most interested in exploring further.

The bigger question I'm taking away from the project is:

AI is getting increasingly good at making decisions.

But production software still has to answer a different question:

“What is the system actually allowed to do with that decision?”

That seems to me like one of the more important engineering problems around agentic AI.

I'd genuinely like feedback from people working on:

\- AI agents

\- fintech

\- distributed systems

\- workflow orchestration

\- financial infrastructure

\- enterprise automation

Where would you draw the boundary between model reasoning, deterministic business logic, policy enforcement and execution?

And what failure modes would you worry about that I haven't covered?

I've attached/shared the architecture and demo for anyone who wants to go deeper