Architecture regulators accept. Processes AI can actually run on.
Building end-to-end process architectures for financial institutions and regulated firms, then wiring AI into them — so the same model that answers to MaRisk, DORA, KWG and internal audit is the one that drives the automation.
Business architecture, implemented
Process architecture, BPMN 2.0 modelling standards, internal control system, written order integration and strategic architecture — built as one connected landscape rather than six disconnected documents.
AI transformation initiatives
AI transformation initiatives and compliant agentic process design: redesign the process first, then let agents run it — with controls, evidence and audit trail attached to every step.
Defining and implementing the BPM framework
This is the plan for the engagement clients ask for most often: process mapping and the information requirements behind it. Five phases, with change communication planned in the first half and executed in the second. Duration depends on resources, prioritisation, the size of the operating model and the number and complexity of processes. Select a phase to see what it delivers.
{{ active.name }}
{{ active.detail }}
The AI automation is built on the business architecture
Business architecture and frameworks are the first step in a regulated institution, and they have to be built into change management. They are the foundation the mandatory risk assessments rest on, which is why every change has to be modelled before it is implemented. If a change reaches production first, the institution loses oversight of the risks that change introduces — and is non-compliant.
That is where the AI comes in. It works on your process documentation and supports the risk assessments built on it. Understanding how a process change affects your application or internal control environment requires reasoning rather than fixed rules. The quality of that reasoning depends on the quality of the documentation: documented processes, clear ownership and a consistent modelling convention.
{{ s.body }}
Every set-up is built for the organisation it runs in. The orchestration layer and the integrations are chosen to fit your existing application environment as much as possible.
The proposed change replaces the current application landscape with Salesforce as the single application executing every task in the process. Two process-embedded controls are affected and have to be rebuilt in the new application. No change to control design is required.
| Control | Embedded in task | Impact | Design change |
|---|---|---|---|
| CID-0001 | Check application form completeness | Rebuild in Salesforce | No |
| CID-0002 | Assess loan risk | Rebuild in Salesforce | No |
Control objectives, logic and ownership remain valid. The execution environment changes, so each control has to be implemented and tested in Salesforce before go-live — until that is confirmed, neither can be considered operating effectively in the target state.
{{ o.body }}
Worth a conversation first
A 45-minute call to look at your landscape and the regulation that you are working under, and to establish whether this approach fits — before either of us commits to anything.
Business architecture, implemented
Six layers, one landscape. Each layer is delivered as a working artefact in your own tooling — Signavio, Camunda or equivalent — not as a slide deck.
{{ ctaLabel }}{{ l.title }}
{{ l.body }}
Choosing the operating model
Where process management sits decides whether standards hold. We pick the model against your size, your project load and your existing centres of excellence.
| Model | Works when | Advantage | Cost |
|---|---|---|---|
| {{ m.name }} | {{ m.when }} | {{ m.pro }} | {{ m.con }} |
The maturity ladder
Process maturity is assessed in parallel with the process mapping. Having that view shows where the gaps are and where the volumes sit, so improvement effort can be placed strategically — on the processes with the highest return on the investment.
Most regulated firms I meet sit between level 2 and 3. Level 4 is where AI enablement stops being a pilot.
Start with what you already have
Most organisations have more documentation than they think, and less structure than they need. A short call is usually enough to see which of these layers are in place and which are missing.
AI transformation that survives the audit
Transformation in regulated institutions rarely fails for lack of strategic intent. It derails when organisations underestimate complexity, protect legacy processes and let technological change outpace regulatory frameworks.
{{ ctaLabel }}The process-management signal
Industry research on why AI programmes underperform — and it is almost never the model.
* Survey — State of Agentic Orchestration and Automation 2026, Camunda
Understanding the root causes behind underperforming AI programmes is what makes the difference. The processes have to be redesigned around what the technology can do — that is what sets the programme up to succeed, and it is work that happens before any of it is built.
How the engagement runs
Process re-engineering combined with graph engineering. On the process side, the workflow itself is redesigned: the steps, handoffs, controls and human checkpoints. On the product side, that workflow is specified and built as a governed AI system — technically documented, owned, measured and improved over time. Delivery is governed like an internal IT project, aligned with MaRisk requirements. Skip either half and the initiative either fails the audit or stalls after the pilot.
How each flow is built
Every process taken from design to scale is built in the same order: measured first, connected second, and only then automated. Agents are only trusted with work that is already measured and evidenced.
Instrument
Capture every input, decision and outcome as structured data, so the process can be measured and every step leaves evidence.
Connect
Link that data to the systems and documents the agents need, through permissioned access only.
Automate
Put agents on the routine path, with deterministic rules and humans handling what they shouldn’t decide.
The steps above build the flow. This is how the agents inside it are designed.
Designing agentic architecture for regulated institutions
Designing for agents that cannot afford to be wrong. In a regulated institution the question is not whether an agent can complete the task — it is whether it understood why the task exists, and whether anyone can reconstruct its reasoning afterwards.
{{ c.title }}
{{ c.body }}
Under the EU AI Act, deployers of high-risk systems are expected to monitor risk continuously and keep mitigating controls in place — which makes auditability a design requirement, not a reporting exercise.
Thinking about an agentic initiative
In most cases the constraint sits in the process rather than the model. A short call is usually enough to tell which one you are dealing with.
Hugrún Lind Arnardottir
Leader in business process management and business architecture
Ten years in operations, eight of them leading — multicultural teams of 15 to 35 people, with first- and second-line responsibility. Lean Six Sigma, business architecture, regulatory compliance and automation meet in the same place: scalable frameworks that hold up under a BaFin audit and still make the day job faster.
Book a discovery call
45 minutes, no deck. Bring one process that hurts — approvals, onboarding, incident handling, third-party risk — and we will map where the architecture is missing and what an AI-assisted version would actually change.
Live availability, straight from my calendar. You will get a confirmation and a calendar invitation immediately.