Domain-Driven Design in Practice: KPI Extraction in Banking

If you would like to explore the technical implementation, system architecture, and concrete product details of our KPI Extraction Tool:

This product is an ideal case study for Domain-Driven Design in practice.

There are two ways to build AI systems: You can take a generic solution and try to adapt it. Or you can start with the domain — and build the technology around it.

We consistently choose the second path.

The “Generic Hammer” Fallacy

Many AI projects begin with tooling: “We’ll take an LLM, add some RAG, and we’re done.” The problem: These systems do not understand business processes or implicit rules. They are unaware of critical validations. They cannot distinguish between relevant and irrelevant edge cases.

The result is a system that works in 80% of cases — but fails exactly where mistakes become expensive.

What Domain-Driven Design Really Means

Domain-Driven Design (DDD) is not a technique. It is a mindset. Technology is not the center — the business problem is.

In practice, this means:

1. Start with the business — not the model
Before making architectural decisions, the process must be understood. What decisions are made? Where do risks emerge? What are the real bottlenecks?

2. Take the domain language seriously
Terms such as “EBIT,” “Leverage Ratio,” or “Working Capital” are not text fragments. They are defined business concepts with rules, dependencies, and context.

3. Make business logic explicit
Experts often operate with implicit knowledge. Successful AI systems turn this into explicit, verifiable logic.

4. Design Human-in-the-Loop intentionally
Automation does not replace expertise — it structures it. Every extraction is traceable, referenced, and reviewable.

Practical Example: 500+ Page Reports, 80% Automation

In the banking sector, large annual reports — often hundreds of pages long — must be analyzed regularly. Quantitative and qualitative KPIs are manually extracted, validated, and transferred into internal systems.

The naive solution would be: feed documents into an LLM and accept the output.

The real challenge is more complex:

• Which KPIs are actually relevant?
• How are conflicting statements handled?
• Which validations are required from a regulatory perspective?
• How is transparency and auditability ensured?

Only through structured domain analysis did it become clear which logic could truly be automated — and which parts must remain controlled.

The result:
80% time savings, break-even after 1.5 months, and improved consistency through standardized validation.

Why Generic AI Solutions Fail in Regulated Industries

• Lack of domain logic: Models recognize terms but not their meaning.
• No business rules: Cross-checks are missing.
• Insufficient context: Forecasts and actual values are mixed.
• No structured error handling: Edge cases remain unclear.

More data does not solve this. Better models do not solve this. Only deeper domain understanding does.

The Uncomfortable Truth

Acquiring domain knowledge takes time. It requires conversations with experts, process analysis, and iteration. It means not starting with implementation immediately.

But that is precisely what separates short-lived demos from production-ready systems.

From Technology Thinking to Problem Thinking

The critical question is not: “Which model should we use?” It is: “Do we fully understand the problem?”

Technology is a tool. Domain understanding is the architecture.

For us, Domain-Driven Design is not a buzzword — it is the foundation for scalable, transparent, and economically meaningful AI systems.

If you would like to explore the technical implementation and product details in depth: