Skip to content

Enterprise Financial Economic Crime (FEC) Platform Engineering Specification

1. Purpose

This document defines the engineering requirements, architecture, design principles, technology recommendations, and implementation guidance for building a configurable enterprise Financial Economic Crime (FEC) operating platform.

Audience:

  • software architects

  • backend engineers

  • frontend engineers

  • DevOps engineers

  • data engineers

  • QA engineers

  • technical product owners

This document assumes the engineering team has strong software expertise but limited Financial Economic Crime domain knowledge.

2. Product Vision

Build a configurable enterprise FEC operating platform that enables financial institutions to design, execute, monitor, and govern financial crime workflows without hard-coded business logic.

The platform is not a point AML tool.

It is a composable operating system for financial crime operations.

Core design principle:

Processes orchestrate work. Decision modules provide intelligence. Governance ensures control.

Initial MVP focus:

  • customer onboarding

  • KYC workflow orchestration

  • name screening

  • customer risk rating

  • basic network analysis

  • analyst case management

  • escalation workflow

  • auditability

  • configuration-driven process design

Excluded from MVP:

  • transaction monitoring

  • transaction screening

  • fraud

  • SAR filing automation

  • advanced ML pipelines

  • multi-jurisdiction regulatory engines

3. Architectural Principles

3.1 Configuration over Code

Business policy changes must not require software deployment.

Configurable:

  • workflows

  • routing rules

  • approval matrices

  • thresholds

  • document requirements

  • module invocation rules

  • business-line templates

Not configurable:

  • core platform security model

  • infrastructure primitives

  • event contracts

3.2 Modular Intelligence Architecture

Each analytical capability must be implemented as a pluggable module.

Examples:

  • Name Screening

  • Customer Risk Rating

  • Network Analysis

  • Entity Resolution

  • Adverse Media

  • Transaction Monitoring (future)

All modules must conform to standard contracts.

3.3 Human-in-the-Loop

No autonomous irreversible decisions in MVP.

System assists analysts. System does not replace accountable decision makers.

3.4 Auditability by Design

Every decision must be reconstructable.

Track:

  • who

  • what

  • when

  • why

  • source inputs

  • configuration version

  • module outputs

3.5 API-First

All platform capabilities must be service-accessible.

UI must consume APIs.

No hidden business logic inside frontend.

3.6 Domain-Driven Design

Use explicit bounded contexts.

Avoid giant shared schema chaos.

Backend

Primary Language: Kotlin

Recommended.

Reasons:

  • JVM maturity

  • excellent concurrency

  • strong typing

  • enterprise maintainability

  • Spring Boot ecosystem

  • better safety than Java

  • suitable for regulated systems

Alternative: Java 21

Not recommended as primary orchestration language: Python

Reason: excellent for analytics, weaker for enterprise transactional orchestration.

Use Python only for analytical modules.

Frontend

TypeScript + React

Reasons:

  • mature ecosystem

  • strong typing

  • excellent enterprise support

  • complex workflow UI suitability

UI framework:

  • React

  • Material UI or enterprise design system

Database

Primary OLTP: PostgreSQL

Reasons:

  • ACID

  • mature

  • JSON support

  • indexing flexibility

  • enterprise-ready

Graph Layer

Neo4j (optional in MVP)

Used for:

  • ownership graph

  • relationship visualization

  • linked entity discovery

Alternative: PostgreSQL recursive modeling initially.

MVP recommendation: start with PostgreSQL only. Add graph engine later.

Workflow Engine

Recommended: Temporal

Alternative: Camunda 8

Recommendation: Temporal for developer-driven orchestration. Camunda if business BPMN modeling is dominant.

For this platform: Temporal is preferable.

Messaging/Event Bus

Kafka

Reasons:

  • scalability

  • event-driven architecture

  • decoupling

  • audit event streaming

OpenSearch / Elasticsearch

Used for:

  • case search

  • customer lookup

  • screening lookup

  • investigation exploration

Identity Management

Keycloak initially

Enterprise SSO later.

Containers

Docker + Kubernetes

Cloud

Cloud-agnostic architecture.

Support:

  • Azure

  • AWS

  • private cloud

  • on-prem

5. System Architecture

Bounded contexts:

  1. Identity & Access

  2. Workflow Orchestration

  3. Configuration Management

  4. Case Management

  5. Customer Domain

  6. Screening Domain

  7. Risk Rating Domain

  8. Network Intelligence

  9. Document Management

  10. Audit/Event Logging

  11. Integration Gateway

Architecture style:

Modular monolith for MVP.

NOT microservices initially.

Reason: Microservices too early create distributed complexity without business value.

Migration path: modular monolith → extracted services.

6. Core Domain Model

Canonical entities:

Customer

Attributes:

  • customer_id

  • customer_type

  • legal_name

  • aliases

  • country_of_incorporation

  • residency_country

  • risk_status

  • created_at

  • updated_at

Individual

  • individual_id

  • first_name

  • last_name

  • date_of_birth

  • nationality

  • pep_flag

LegalEntity

  • entity_id

  • registration_number

  • entity_type

  • incorporation_country

OwnershipRelationship

  • parent_entity_id

  • child_entity_id

  • ownership_percentage

  • control_type

ScreeningResult

  • result_id

  • module_type

  • match_status

  • score

  • rationale

  • source_list

RiskAssessment

  • assessment_id

  • customer_id

  • score

  • risk_level

  • rule_version

  • rationale

Case

  • case_id

  • case_type

  • state

  • priority

  • assigned_to

  • created_at

Task

  • task_id

  • workflow_instance_id

  • owner

  • due_date

  • state

WorkflowInstance

  • workflow_instance_id

  • workflow_definition_id

  • current_state

  • config_version

Decision

  • decision_id

  • actor_type

  • actor_id

  • decision_type

  • rationale

Document

  • document_id

  • type

  • storage_reference

  • classification

7. Workflow Engine Requirements

Must support:

Process definition

Configurable workflows.

Examples:

  • onboarding

  • periodic review

  • screening escalation

State transitions

Explicit finite-state transitions.

Conditional routing

Examples: IF high risk THEN EDD.

Parallel execution

Run screening + risk rating simultaneously.

Human tasks

Manual approvals.

SLA timers

Deadline management.

Retry policies

For failed module execution.

Compensation logic

Rollback handling.

8. Decision Module Standard Contract

Input:

  • request_id

  • module_type

  • entity_reference

  • payload

  • context

  • config_version

Output:

  • status

  • decision

  • score

  • rationale

  • evidence

  • execution_metadata

Requirements:

  • idempotent

  • versioned

  • auditable

  • timeout-aware

9. Name Screening Module

Capabilities:

  • exact match

  • fuzzy match

  • alias matching

  • transliteration support

Inputs:

  • names

  • aliases

  • country

  • date of birth (optional)

Outputs:

  • hit/no-hit

  • confidence

  • matched entry

  • explanation

Implementation guidance: Start simple. Do not overbuild fuzzy NLP initially.

10. Customer Risk Rating Module

Initial implementation: rules engine.

Risk factors:

  • geography

  • customer type

  • ownership complexity

  • PEP exposure

  • product exposure

Output:

  • Low / Medium / High

  • rationale trace

Implementation: configuration-driven rules.

No ML initially.

11. Network Analysis Module

MVP capabilities:

  • ownership graph visualization

  • linked entities

  • shared identifiers

Implementation: simple relationship traversal.

Do not build advanced graph intelligence initially.

12. Case Management Requirements

Capabilities:

  • case creation

  • queue management

  • assignment

  • reassignment

  • escalation

  • notes

  • attachments

  • decision logging

  • closure

UI requirements: Single analyst workspace.

13. Configuration Engine

Must manage:

  • workflow definitions

  • thresholds

  • approval rules

  • document requirements

  • routing rules

Governance:

  • versioning

  • approvals

  • rollback

  • audit

14. Security Model

Requirements:

  • RBAC

  • least privilege

  • SSO readiness

  • MFA readiness

  • audit access logging

Roles:

  • analyst

  • compliance reviewer

  • approver

  • admin

  • auditor

15. Audit Architecture

Immutable append-only event model.

Track:

  • login

  • data access

  • config change

  • decision action

  • workflow transition

  • module execution

16. API Standards

REST JSON APIs.

Rules:

  • versioned endpoints

  • idempotency keys

  • correlation IDs

  • pagination

  • structured error schema

17. Testing Strategy

Required:

  • unit tests

  • integration tests

  • contract tests

  • workflow tests

  • security tests

  • performance tests

Coverage target: minimum 80% business logic.

18. Development Process

Method: vertical slices.

Order: 1. auth + RBAC 2. canonical domain model 3. workflow engine 4. case management 5. configuration engine 6. name screening 7. risk rating 8. network analysis 9. analyst UI 10. audit hardening

19. Anti-Patterns to Avoid

Do NOT:

  • start with microservices

  • hardcode workflows

  • embed business logic in UI

  • mix audit and transactional concerns poorly

  • introduce ML too early

  • overengineer graph analytics

  • skip configuration governance

20. MVP Acceptance Criteria

Platform is acceptable when:

  • onboarding workflow configurable

  • analyst can process case end-to-end

  • name screening works

  • risk scoring works

  • audit reconstruction works

  • approvals function

  • new workflow can be configured without code