The Cost of Building Pre-Execution Compliance In-House

Every institution evaluating pre-execution compliance infrastructure for AI-driven transactions faces the same question.

Build or buy?

The in-house build option is attractive on its face: full control over the architecture, integration with existing systems, no vendor dependency. Every technology leader has a version of the argument for it.

It is also consistently underestimated — in scope, in timeline, and in what it costs to operate while the build is underway.

This article sets out what an in-house build of pre-execution compliance infrastructure actually requires. Not to argue against it. But because institutions that understand the full scope make better decisions.

What It Actually Is

A pre-execution compliance layer is not a set of API calls or a rule-engine wrapper.

It is a production-grade system that must intercept every AI-generated transaction instruction before it reaches the payment rail; run a complete compliance assessment against a configurable policy ruleset in milliseconds; produce a binary, explainable decision — cleared or held — with a full audit record; handle concurrent transaction loads without introducing perceptible latency; write an immutable, tamper-proof audit log for every decision; support human review workflows for held instructions, including hold queues, escalation paths, and resolution mechanisms; integrate with existing AML/CFT and risk systems; and remain aligned with evolving MAS regulatory guidance.

Each of these requirements carries its own engineering complexity. Together, they constitute a system most institutions' internal teams have not built before — because the need for it did not exist until AI agents began executing transactions.

The Timeline Reality

In Sidian's assessment, based on the component requirements above, institutions should plan for 12 to 24 months from project approval to a production-grade system that meets regulatory confidence standards.

Four factors consistently drive this timeline.

Regulatory alignment. MAS FEAT, MAS AML/CFT Notice, and MAS TRM Guidelines each impose specific requirements on the system — explainability, audit records, data residency, access controls, and incident response procedures. Translating these into a technical specification that survives legal and compliance review adds weeks to the design phase alone.

Production-grade latency under concurrent load. A pre-execution compliance check that adds perceptible latency to every compliant transaction is not commercially viable. It will be bypassed or disabled under operational pressure. Achieving millisecond response times at production volumes — with failover, redundancy, and Singapore data residency — requires infrastructure investment and load testing that does not happen quickly.

Audit log immutability. The MAS AML/CFT Notice's 7-year record-keeping requirement, combined with the explainability expectations under MAS FEAT, mandates an audit log that cannot be modified after a record is written. Building this correctly — with cryptographic integrity verification and export capability — requires specialist knowledge of write-ahead log architectures.

Compliance team integration. A hold queue, notification system, escalation path, and resolution workflow must integrate with the institution's existing compliance operations. This component is the most frequently overlooked in initial scoping. It is also the one that determines whether the system is operationally viable.

The Timeline Problem

Here is the difficulty with a 12 to 24 month build timeline.

The MAS obligation to demonstrate explainability, accountability, and audit records for AI-driven transactions does not begin when the in-house build is complete. It begins when the first AI-generated transaction executes.

An institution that approves an in-house build in Q1 2026 — with a realistic completion date in Q1 to Q3 2027 — is operating AI-driven transaction flows without pre-execution compliance infrastructure for 12 to 24 months. During that window, every AI-generated transaction is a transaction for which the institution cannot produce the explainability record that a regulatory examination under MAS FEAT would require.

The in-house build does not solve the problem. It defers the solution while the regulatory obligation accumulates.

The Decision Framework

The build vs buy decision is not purely technical. It involves regulatory timeline, institutional risk appetite, and opportunity cost.

Institutions with engineering capacity and timeline headroom to build properly — and the regulatory bandwidth to operate without a compliant pre-execution layer during the build period — may find the in-house path appropriate. Those institutions are not common.

For most MAS-regulated institutions deploying agentic AI, the more pressing question is: what is the cost of the compliance gap while the in-house build proceeds?

That cost is not measured in engineering hours. It is measured in regulatory exposure — the inability to produce explainable, auditable compliance records for every AI-generated transaction that executes during the build window.

Purpose-built solutions compress the deployment timeline from months to weeks. Institutions evaluating this option should assess vendor MAS regulatory alignment, data residency, patent status, and the depth of institutional integration support before committing.

The question is not whether in-house is possible. It is whether the timeline is appropriate — given that the regulatory obligation began with the first transaction your AI ever executed.

This article is for informational purposes only and does not constitute legal or regulatory advice. The timeline estimates reflect Sidian's assessment based on component complexity and should be validated against each institution's specific technical environment. Institutions should assess their compliance obligations with their own legal and compliance counsel. Sidian Pte. Ltd. is a Singapore RegTech providing pre-execution AI compliance infrastructure for MAS-regulated institutions.