Far Rainbow — Lecco, Italia
IT Discuss your project Contact

Financial services · compliance

When the regulator asks why, the system answers with the sentence.

An international financial holding operating through subsidiaries in more than twenty countries asked for two things: a way to check its internal policies against what each national regulator actually requires, and a way to check its payment and trading flows against the same body of law. Every tool they evaluated stopped at the same place.

Built
2025–26
Client
under NDA
Team
11
Status
in implementation

The problem

Between the law and the running rule, there is a person with a PDF

The group holds an investment-firm licence, brokerage licences, payment-institution licences and a banking licence, and it uses them: equities, ETFs, bonds, options and futures across several continents; dealing and market-making; investment research and advisory; underwriting; retail and corporate banking and mortgages; insurance products; payment processing. Each of those activities is regulated, each jurisdiction regulates it differently, and most of them write their rules in their own language.

The two questions they needed answered sound administrative and are not. First: does each internal policy document actually satisfy what the regulator of that country requires? Second: does each payment and each trade comply with the rules on money laundering, fraud and market abuse — manipulation schemes, coordinated pumps, structuring — in the jurisdiction it touches?

Both questions already have an answer in most institutions. The answer is a person. A compliance officer or an analyst reads the regulation, decides what it means in operational terms, and writes a rule into a monitoring engine. That chain — from a specific sentence of a specific article to a specific predicate running against a transaction stream — exists in that person's head, in a spreadsheet, and in a slide deck. It does not exist in the system.

Competitive analysis

Three weak links, found with the client rather than claimed at them

Before anything was designed, we went through the tools on the market together with the client's own people. The category is mature and the products are good at what they do. All three gaps below are upstream of what they do.

  • The rules are hand-made. Existing systems execute rules that an MLRO or an analyst wrote by hand after reading documentation. That is skilled work, and it is still manual transcription between two representations — which means it inherits every property of manual work: omissions, drift between jurisdictions, and no mechanical way to tell whether the catalogue covers the regulation or only the parts somebody got to.
  • The alert cannot explain itself. A trigger shows a suspicious transaction and, at best, the name of the rule that flagged it. It does not carry a reference to the regulatory text that makes it suspicious. So the material a supervisor expects — this transaction, this obligation, this clause — has to be assembled by hand afterwards, by the same people the system was supposed to free.
  • The "AI" products translate first. Tools that advertise automatic reading of regulatory documents, in practice, translate the document into English, send the translation to a model, and generate rule suggestions from the output. For a group operating in more than twenty legal systems with their own languages, that inserts an invisible lossy step exactly where precision is the product. Our team had already spent years on extracting meaning from text in its original language; this is where that work paid for itself.

How it works

The chain the system makes machine-readable

Regulatory text is compiled, not summarised. A paragraph becomes a typed structure — actors, events, states, obligations, prohibited patterns — in which every term carries the exact character range of the source passage it came from. That structure compiles into declarative logic, and the character ranges travel with it all the way to the runtime alert.

From a sentence of regulation to a defensible alert, and back Authoring, once per regulation: the regulation in its own language becomes a typed ontology in which every term carries the character range of its source passage, which compiles into declarative rules in sCASP with Event Calculus. Runtime, on every transaction: live payments and orders run through the solver, which emits an alert with a justification tree. A provenance link runs from that alert back to the exact characters of the regulation that justify it. AUTHORING — ONCE PER REGULATION, AND AGAIN WHEN IT CHANGES Regulation, as written in its own national language Typed ontology every term keeps its source span Executable rules sCASP · Event Calculus the rule base the engine runs RUNTIME — ON EVERY TRANSACTION Live flow payments, orders, account activity Solver deterministic, re-runnable Alert + justification the tree that proves the alert every alert resolves to the exact characters of the clause that justifies it
The loop is the product. Compiling regulation into rules is useful; being able to walk backwards from a live alert to the characters of the clause behind it is what an inspection actually asks for.

Why a solver rather than a model

Large language models do real work here, and they do it at authoring time: splitting text, recognising the shape of an obligation, proposing the scenarios a clause implies. They are not in the runtime path, and that is the whole design. Runtime decisions are taken by sCASP — a declarative logic solver whose defining property is that it produces a justification tree for every fact it derives. Explainability is not a layer built on top; it is how the engine runs.

Temporal and compositional patterns — a sequence of orders and cancellations by the same actor inside a window, a state of false market impression that persists across several events, an obligation that must be discharged within a deadline — are expressed in Event Calculus, which is the formalism built for reasoning about events that happen, states that hold, and how they relate over time. These patterns flatten badly into decision trees and do not survive being asked of a model one transaction at a time.

The practical consequence is boring and decisive: the same input produces the same output, every time, and the output carries its own argument.

The system

Two tools, for two groups of people who do not work alike

01 · For legal and the MLRO

An assistant for working with regulatory documents: ask what a body of law requires on a given activity, see which internal policy answers it and which does not, and get the answer with the passages behind it rather than a paraphrase. This is the tool that turns "we think we are compliant" into a list with citations.

02 · For the monitoring team

A workspace where rules are authored, versioned and reviewed, and where the live flow of payments and orders is checked against them as it happens. Each alert arrives with its justification tree and its link back into the source document.

The team — 11 people

  • 1project manager
  • 1system analyst
  • 1UI/UX designer
  • 5ML, data and trading analysts
  • 1QA engineer
  • 1DevOps engineer
  • 1full-stack developer (Jmix)

Five analysts and one developer. That ratio is the whole character of this engagement: the difficulty was never in building screens, it was in understanding what a regulation requires and what abusive trading actually looks like. The application layer had to be carried by one person — which is a demand you can only make of a framework that generates most of it.

Why the interface is Jmix

The parts of the system that do the reasoning are written in whatever each job needed. The interface — both tools — is built on Jmix, and the reason is not habit.

This is an internal enterprise system with a large domain model, a modest number of users and extremely serious access control: a single screen can hold a client's transaction history, a draft suspicion, or an unpublished finding about an employee. Jmix declares permissions on entities, attributes and rows and enforces them when data is loaded rather than when it is displayed — a field a user may not see never reaches the browser. In a system that auditors will walk through, that distinction is the argument.

The rest is economics and continuity. It is Spring Boot and Java underneath, so the holding's own engineers can maintain it without hiring for a framework nobody has heard of; the subscription is per developer seat with no runtime or per-user fee, which matters when the user count is a compliance department and the deployment count is twenty subsidiaries. We are also the seller of record for Jmix licences in Italy, which we would rather tell you than have you work out.

Where this stands, honestly

This system is in implementation, not in full production. The compilation pipeline, the rule authoring workspace and the two interfaces exist and run; the work of covering each jurisdiction's body of law is exactly the work that takes time, and it is in progress. We would rather tell you that than write this page in a tense the engagement has not reached.

For the same reason there are no detection rates, no false-positive reductions and no alert volumes on this page. Several of those numbers do not exist yet, and the ones that do belong to the client's operations rather than to our marketing. When there is something measured and publishable, it will appear here with its method next to it.

Questions

What compliance and technology ask first

Why not just use a large language model for this?

We do use them — inside the pipeline, at authoring time, for segmenting text and proposing structure. What we do not do is put one in the runtime path. A monitoring decision has to be deterministic: the same transaction and the same rule base must produce the same answer today, next quarter and in front of an inspector two years from now. A model that paraphrases cannot promise that, and it cannot show the reasoning step it took. The engine that runs against live transactions is a solver, not a model.

Does the system decide whether something is suspicious?

No. It produces an alert and the reasoning behind it: which rule fired, which facts satisfied it, and which passage of which document put that rule there. A human makes the decision, which is both how the regulation is written and how liability works — in most regimes the compliance officer is personally accountable. What changes is that the human starts from an argued position instead of from a row in a queue.

What happens to the national languages?

Meaning is extracted in the language the regulation is written in. This is the part we built differently on purpose. The common approach — translate everything into English, analyse the translation, generate rules from it — inserts a lossy step exactly where precision matters, and the loss is invisible afterwards because the translation looks fluent. For a group operating across more than twenty legal systems, that is not a quality problem to be polished later; it is a hole in the control environment.

Can it work with the transaction-monitoring system we already have?

Yes, and that is the usual shape. The upstream half — the regulatory inventory, the rule catalogue, the provenance chain — has value even if your existing engine keeps executing the rules: it is the documentation of why those rules exist, which is what an inspection asks for. Running our engine on the stream as well is the second step, not the price of entry.

What happens when a regulation changes?

The new text is compiled the same way the old one was, and the two rule sets are compared structurally: which obligations are new, which thresholds moved, which exemptions disappeared, which existing controls are now insufficient. That diff is the deliverable a compliance team currently produces by hand, slowly, every time a regulator publishes.

Why is the interface built on Jmix?

Because it is an internal system with a large domain model, a small number of users and very serious access control — the exact shape Jmix was designed for. Permissions are declared on entities, attributes and rows and enforced when data is loaded, which matters when a screen can contain a client's transaction history. It is Java and Spring underneath, so the client's own engineers can maintain it, and the licensing carries no per-user or runtime fee. We also sell Jmix licences in Italy, which we would rather disclose than have you discover.

If this is your problem

The test is simple: can your monitoring cite its source?

Take one rule in production today and ask which sentence of which document put it there, and who can prove it. The answer tells you whether this page is about you.

Start small

One regulation, one rule set

We compile a body of law you already struggle with and show you the catalogue, the coverage map and the provenance chain. It stands on its own, whatever you decide afterwards.

 The interface

Why we build these on Jmix

Access control enforced at load time, a large domain model, and no per-user licence. What the platform is and where it does not fit.