AI for Financial Knowledge Work: Architecture Design and Compliance Practices

1. Why finance needs a dedicated approach

Much of the work inside financial institutions is knowledge work. Inputs include structured data—market data, transaction records, and account information—and unstructured documents such as fundraising materials, research reports, contracts, regulatory filings, and client communications. Outputs are judgments or documents with a clear owner. A general question-answering system can explain what something is, but it cannot independently decide whether a transaction is compliant or whether figures in a document can be traced back to a source.

Typical use cases include:

• Drafting and checking investment-banking materials, such as pitch books and track-record presentations
• Document checks in client due diligence and anti-money-laundering screening (KYC)
• Organizing data for financial analysis and valuation models
• Briefing packs before client meetings
• Scenario analysis for portfolio rebalancing
• Explanatory materials for estate and tax planning
• Document review in insurance underwriting
• Risk-attribution analysis for asset-management portfolios

These cases share three traits: many data sources, strict rules, and a high cost of error. A qualified person must still sign off. The technical focus is therefore not the model alone, but how data, rules, permissions, and review work together.

2. Core technical challenges

2.1 Heterogeneous and time-sensitive data

Financial data sits in market-data systems, warehouses, custody platforms, CRM systems, and office documents. The same metric can be defined differently across systems and updated on different schedules. If the system reads stale data, the analysis may look plausible while being impossible to trace to a trusted source.

2.2 Compliance and access boundaries

Different roles may see different slices of client data. An analysis assistant that can read every client file across departments creates an unauthorized-access risk. Permissions should reuse the institution’s existing access-control system rather than a second rule set in the AI layer, which would drift out of sync.

2.3 Traceability and auditability

During a regulatory review, the institution must explain the basis of a conclusion. The system must record the version of the input data, retrieved document passages, calculation steps, and final output so the audit trail is complete. If any link is missing, the conclusion is hard to recheck.

2.4 Accountability

Model output is only a draft or a supporting judgment. Final decisions and signatures belong to qualified staff. The system should mark what was machine-generated and what a person has confirmed.

3. Reference architecture

Split the system into five layers, each with a single responsibility, so layers can be tested and replaced independently.

1. Data access. Read-only connectors to market data, accounts, documents, and similar sources, with unified authentication and least-privilege access.
2. Knowledge processing. Parse documents, chunk them, attach metadata, build a searchable index, and keep original page or cell locations for trace-back.
3. Reasoning and tools. The model interprets the task and calls retrieval and calculation tools. Amounts and ratios are computed by verified deterministic code. The model only organizes language and explains results.
4. Compliance controls. Before release, run rule checks: sensitive-data redaction, blocked phrasing, threshold checks, and conflict-of-interest prompts.
5. Human review. Critical outputs enter a review queue. Reviewers check cited sources item by item and approve or reject.

Illustrative pseudocode:

function handle_request(user, task):
    scope = permission_service.get_scope(user)
    sources = retriever.search(task.query, filter=scope)
    facts = calc_engine.compute(task.metrics, sources.structured)
    draft = model.generate(task, sources.snippets, facts)
    violations = compliance.check(draft, policy=user.region_policy)
    if violations.has_critical():
        return reject_with_reason(violations)
    audit_log.record(user, task, sources.ids, facts, draft)
    return review_queue.submit(draft, reviewer=task.owner)

The pseudocode encodes three rules: filter by permission before retrieval, compute numbers in deterministic code, and run rule checks and write an audit record before the output leaves the system.

4. Design principles

4.1 Retrieve first, then generate

Model output should rest on citable source material. Each material claim should carry a source identifier so reviewers can open the original. Claims without a source should be marked low confidence and not used externally as-is.

4.2 Separate numbers from language

Large models are good at wording and poor at high-precision arithmetic. Calculations should come from code, with the calculation steps attached. The model explains and describes them. Both should be labeled in the output.

4.3 Check permissions first

Access checks belong before retrieval, not only when results are displayed. Otherwise sensitive content can still enter the model context and leak indirectly in the output.

4.4 Split work between people and machines

Classify tasks into three groups: formatting that can be automated (table layout, consistent terminology), analytical conclusions that need human confirmation, and decisions and signatures that a person must complete independently. Clearer categories make risk boundaries easier to hold.

5. Evaluation metrics and rollout

Before go-live, build an evaluation set that covers routine cases, edge cases, and abnormal inputs. Track:

• Factual accuracy: how closely key figures match the source material
• Citation verifiability: whether a conclusion can be located in a specific source
• Compliance violation rate: the share of outputs that trigger a rule
• Review edit rate: the share of items humans change during review, as a measure of practical usefulness
• Latency and unit cost: reported separately by task type

Roll out in three stages. First, internal drafts only, with no external output. Second, a small-team pilot focused on the review edit rate. Third, broader use only after metrics are stable, with a switch that can turn the feature off at any time.

6. Common mistakes

Treating the model as a database. Parametric memory is unreliable. Facts should come from source data retrieved at the time of the request.

Judging only the demo. Demos usually use clean samples. Production must be tested on real, messy data.

Ignoring operations. Source changes, rule updates, and model version changes all need change control and regression tests. Otherwise live behavior drifts away from the evaluation results.

Automating too far. Removing human review from high-risk steps blurs accountability and spreads errors faster.

7. Implementation path

1. Map the business process and mark data sources, rule requirements, and accountable owners.
2. Pick a pilot with a clear boundary and a manageable cost of error, such as pre-meeting briefings.
3. Build data access and permissions so connections are read-only and follow least privilege.
4. Build an evaluation set and set go-live thresholds.
5. Run the pilot, collect review feedback, and iterate rules and prompt templates.
6. Expand to higher-value cases one at a time, and reassess risk at each expansion.

AI in finance is a system that has to be maintained over time. The stronger the frame of data, rules, permissions, and human responsibility, the more efficiently technical capability turns into trusted business value.