In regulated lending, every dossier carries multiple people in multiple roles. Compliance data must land exactly, per person, inside generated contracts and anti-money-laundering documentation. We engineered two systems that make that deterministic.
In regulated lending, every dossier carries multiple people in multiple roles: the applicant, co-obligors, guarantors, third parties. Each of them owes the process compliance data, and that data has to land, exactly and per person, inside generated contracts and anti-money-laundering documentation. Done manually, this means re-entering compliance answers into documents, person by person, with every re-entry a chance to put the right data on the wrong person, and every regulatory change a round of template surgery.
AML regulation defines what must be asked and evidenced; the questions change, and the platform must absorb those changes without engineering releases. A generated document may reference any person in any role, and in a regulated contract a plausible-but-wrong value is worse than an error. Compliance scenarios (AML, suspicious-activity, politically-exposed-person) must raise notifications, and every change must be auditable.
Two engines working together inside the lending platform. A schema-driven questionnaire engine, where compliance forms are configuration: defined per product, versioned, and changeable without code releases. And a deterministic placeholder engine for document generation: when a compliance form is saved, the system generates the tokens that documents can reference, both role-level and person-specific; at document generation, every token resolves to exactly one concrete value under strict rules, with no fallback and no cross-role substitution. If the right value does not exist, the system says so rather than guessing. Compliance scenarios trigger notifications automatically, and changes publish audit events at the module boundary.
Stack: Java Spring Boot, PostgreSQL, Redis, REST services inside the multi-tenant lending platform.
Compliance questionnaires change as configuration, not code: regulatory updates ship without an engineering release.
Every document token resolves to exactly one value, deterministically: no silent fallback, no wrong-person data in a regulated contract.
AML, suspicious-activity and politically-exposed-person scenarios raise automatic notifications instead of relying on someone noticing.
Every change publishes an audit event: the compliance trail is a property of the system, not a discipline asked of its users.
Forms defined as versioned configuration make regulatory change an operations task instead of an engineering project.
Rationale: AML requirements change on the regulator's schedule, not the release schedule.
Trade-off accepted: A more complex engine up front, accepted once instead of paying template surgery forever.
The engine either resolves to exactly the intended person's value or fails loudly.
Rationale: In regulated documents, resolving a token to a plausible neighbouring value is the most dangerous failure mode there is.
Trade-off accepted: Stricter authoring discipline for templates, accepted because a visible error is fixable and a silent one is a compliance incident.
Publishing events where the change happens makes the trail structural.
Rationale: Auditability retrofitted at the edges always leaks.
Trade-off accepted: Event plumbing on every write path.
The engine's strictness was designed in from the start, but its guarantees were documented properly only after the fact, when questions about resolution behaviour kept resurfacing. We now treat the behavioural contract of a compliance engine (what resolves, what fails, and why) as a first-class deliverable written alongside the code, because in regulated systems the documentation of behaviour is part of the compliance surface itself.
This engine sits inside a multi-tenant lending platform. The compliance-engineering patterns here are the same class of work we bring to TRACE and to DPDP engineering assurance: verify what systems actually do, engineer the trail, and fail loudly when data cannot be resolved safely.
If your operation generates regulated documents from compliance data, we can map where manual assembly, silent fallbacks, or audit gaps create risk before you commit build scope.