BRD/FRD Documentation Guide

Overview

A comprehensive guide to documenting business and functional requirements that prevent scope creep, reduce rework, and ensure stakeholder alignment. Includes templates, examples, and best practices from Tier-1 implementations.

Document Structure

Business Requirements Document (BRD)

Purpose: Define WHAT the business needs and WHY Audience: Business stakeholders, executives, project sponsors Focus: Business outcomes, not technical solutions

Functional Requirements Document (FRD)

Purpose: Define HOW the solution will work Audience: Development teams, testers, architects Focus: Detailed functional specifications

BRD Template

1. Executive Summary

PROJECT: [Trade Surveillance Enhancement]
SPONSOR: [Head of Compliance]
BUSINESS OWNER: [Compliance Manager]
REQUESTED BY: [FCA Regulatory Review]
DATE: [15 January 2025]
VERSION: 1.0

BUSINESS PROBLEM:
Current trade surveillance system generates excessive false positives (85% false positive rate),
consuming 40 hours/week of analyst time and creating risk of missing genuine market abuse.

BUSINESS OBJECTIVE:
Reduce false positive rate to <20% while maintaining 100% detection of suspicious activity,
freeing up 30 hours/week for proactive risk analysis.

SUCCESS CRITERIA:
- False positive rate reduced from 85% to <20% (measured over 3 months)
- Zero false negatives (all genuine suspicious activity detected)
- Analyst investigation time reduced by 75%
- System processes 10,000 trades/day with <1 minute latency

BUSINESS VALUE:
- Cost Saving: £180k annually (reduced analyst time)
- Risk Reduction: Improved detection of market abuse, reduced regulatory risk
- Efficiency Gain: 30 hours/week reallocated to proactive surveillance
- Regulatory: Demonstrates continuous improvement to FCA

TIMELINE:
- Discovery & Requirements: 4 weeks
- Solution Design: 3 weeks
- Development & Testing: 12 weeks
- UAT & Training: 3 weeks
- Go-Live: Week of [Date]

BUDGET:
- Total Project Cost: £250k (software: £150k, implementation: £80k, training: £20k)
- 3-Year ROI: 116% (£540k savings vs £250k cost)

2. Business Context

Current State

As-Is Process:

1. Trading activity occurs across 5 venues (LSE, NYSE, BATS, etc.)
2. End-of-day batch job ingests trade data (T+0, 11pm)
3. Rules engine applies 47 surveillance rules
4. System generates average 850 alerts per day
5. 2 analysts manually review each alert (45 min average)
6. ~700 alerts (85%) closed as false positives
7. ~150 alerts require further investigation
8. ~10 alerts escalated to MLRO per month

Pain Points:

• Alert Fatigue: 85% false positive rate demoralises analysts
• Delayed Detection: Batch processing means T+1 detection (too late for intraday abuse)
• Manual Inefficiency: 40 hours/week spent on false positives
• Regulatory Risk: FCA identified risk of "missing the needle in the haystack"
• Poor Tuning: Rules are hard-coded, require IT change to adjust thresholds

Future State

To-Be Process:

1. Trading activity occurs across 5 venues (no change)
2. Real-time streaming ingests trade data (<1 min latency)
3. ML-enhanced rules engine applies tuned surveillance logic
4. System generates ~125 alerts per day (targeted reduction)
5. Automated triage categorises alerts by risk score
6. Analysts review high-risk alerts first (15 min average)
7. ~25 alerts (20%) closed as false positives
8. ~100 alerts require investigation (genuine suspicious activity)
9. ~10 alerts escalated to MLRO per month (no change in escalations)

Benefits:

• Improved Accuracy: 20% false positive rate (vs 85% today)
• Real-Time Detection: <1 minute latency (vs T+1 today)
• Efficiency: 75% reduction in analyst investigation time
• Better Tuning: Business users can adjust thresholds without IT
• Audit Trail: Enhanced lineage and explainability for regulators

3. Stakeholder Analysis

4. Business Requirements

Functional Requirements Summary

Non-Functional Requirements Summary

5. Scope

In Scope

Trade surveillance for equity trading (LSE, NYSE, BATS, Chi-X, Turquoise) 8 core market abuse patterns (layering, spoofing, wash trading, etc.) Integration with existing Actimize case management system Training for 2 surveillance analysts and 1 compliance manager Data migration of last 12 months of historical alerts

Out of Scope

✗ FX and Fixed Income trading (separate project) ✗ Post-trade surveillance (settlement failures, etc.) ✗ Replacement of Actimize case management system ✗ Suspicious Transaction Report (STR) generation (manual process retained) ✗ Trader desktop integration

Assumptions

• Trade data feeds from existing OMS remain unchanged
• Compliance team provides SME support for rule calibration
• Infrastructure team provides AWS cloud environment
• 3rd party vendor (ThetaRay) provides ML model

Dependencies

• OMS vendor provides API access to real-time trade data
• AWS account provisioning completed by infrastructure team
• ThetaRay software licenses procured
• Actimize API documentation provided by vendor

Constraints

• Must go-live before FCA inspection (Q2 2025)
• Budget cap of £250k
• Cannot disrupt existing surveillance during implementation
• Must support current analyst workflows (minimal retraining)

6. Success Metrics

7. Risk Register

FRD Template

1. Functional Specification Overview

DOCUMENT: Functional Requirements - Trade Surveillance Enhancement
VERSION: 1.0
DATE: [Date]
STATUS: Approved

RELATED DOCUMENTS:
- Business Requirements Document v1.0
- Technical Design Document v1.0
- Data Integration Specification v1.0

PURPOSE:
This document specifies HOW the trade surveillance system will function to meet
the business requirements defined in the BRD. It serves as the contract between
business and development teams.

2. Use Cases

Use Case UC-001: Real-Time Alert Generation

Primary Actor: System (automated) Stakeholders: Surveillance Analyst Preconditions: Trade data received from OMS Trigger: Trade executed and sent to surveillance system

Main Success Scenario:

1. System receives trade message from OMS via Kafka
2. System enriches trade with reference data (counterparty, instrument, trader)
3. System applies 8 surveillance rules to trade
4. If rule triggered, system calculates risk score using ML model
5. System creates alert in database with risk score and supporting evidence
6. System sends notification to analyst dashboard
7. If High-risk alert, system sends email to compliance manager

Extensions (Alternative Flows):

• 2a. Reference data not found → Log error, alert marked "Data Quality Issue"
• 4a. ML model unavailable → Use rule-based score only, flag for review
• 6a. Analyst dashboard unavailable → Queue notification for retry

Postconditions: Alert is created and visible to analysts

Business Rules:

• BR-001: Alert must be generated within 1 minute of trade execution
• BR-002: Risk score must be between 0-100 (0=low risk, 100=high risk)
• BR-003: High-risk alerts (score >70) trigger immediate email notification

Use Case UC-002: Alert Investigation

Primary Actor: Surveillance Analyst Stakeholders: MLRO, Compliance Manager Preconditions: Alert exists in system Trigger: Analyst selects alert from queue

Main Success Scenario:

1. Analyst opens alert from prioritised queue
2. System displays alert details:
   • Trade details (instrument, quantity, price, time, trader, counterparty)
   • Rule(s) triggered and threshold breached
   • Risk score and contributing factors
   • Historical context (trader's recent activity, similar alerts)
   • Market context (price movements, volume)
3. Analyst reviews supporting evidence
4. Analyst makes decision: Close as False Positive / Escalate for Investigation
5. System prompts for mandatory comment (min 50 characters)
6. Analyst enters comment and submits decision
7. If "Escalate", system creates case in Actimize with all context
8. System updates alert status and logs decision with timestamp and user ID

Extensions:

• 4a. Analyst needs more information → Request additional data from trader
• 7a. Actimize API unavailable → Queue case creation for retry, notify analyst

Postconditions: Alert is closed or escalated; decision is logged

Business Rules:

• BR-004: Analysts must action high-risk alerts within 4 hours
• BR-005: All decisions require mandatory comment (min 50 chars)
• BR-006: Escalated alerts auto-create case in Actimize within 5 minutes

3. Functional Requirements Detail

FR-001: Real-Time Trade Ingestion

Description: System shall ingest trade data from OMS in real-time via Kafka message queue

Inputs:

• Trade message from OMS (JSON format)
• Fields: TradeID, Instrument, Quantity, Price, Timestamp, TraderID, Venue, CounterpartyID

Processing:

1. Validate message schema (reject if invalid)
2. Enrich with reference data:
   • Trader name and desk from HR system
   • Instrument details from market data provider
   • Counterparty name from CRM
3. Calculate derived fields:
   • Trade value = Quantity × Price
   • Time since market open
4. Store in trade data lake (S3) and operational database (PostgreSQL)

Outputs:

• Trade record in database (available for surveillance rules)
• Trade logged to audit trail

Performance: Process 10,000 trades/day with <1 minute latency (95th percentile)

Error Handling:

• Invalid message schema → Log error, send to dead letter queue
• Reference data unavailable → Proceed with incomplete enrichment, flag for manual review

FR-002: Surveillance Rule Execution

Description: System shall apply 8 surveillance rules to each trade in real-time

Rules:

1. Layering: Multiple orders placed and cancelled without execution
2. Spoofing: Large order cancelled shortly after smaller opposite-side execution
3. Wash Trading: Trader buys and sells same instrument within 1 hour
4. Marking the Close: Large trade in final 5 minutes of trading
5. Pump and Dump: Trader buys then promotes stock (requires external data)
6. Front Running: Trader executes before client order
7. Insider Trading: Trading ahead of corporate announcement (requires screening vs announcements)
8. High Frequency Manipulation: Excessive order-to-trade ratio

Inputs:

• Trade record (from FR-001)
• Historical trades for same trader/instrument (look-back window: 30 days)
• Order data from OMS (for layering/spoofing detection)

Processing: For each rule:

1. Check if trade meets rule conditions
2. If triggered, collect evidence (e.g., related orders, price movements)
3. Calculate rule-specific score (0-100)

Outputs:

• Rule trigger flag (yes/no) per rule
• Rule-specific score per triggered rule
• Evidence package (related trades, orders, market data)

Business Rules:

• Rules applied in parallel (not sequential)
• If multiple rules trigger, highest score determines alert priority
• Rule thresholds configurable by compliance manager (no code changes)

FR-003: ML Risk Scoring

Description: System shall calculate ML-enhanced risk score for each triggered alert

Inputs:

• Rule trigger flags and scores (from FR-002)
• Trader historical behaviour (past 90 days):
  • Number of previous alerts (false positive rate)
  • Trading patterns (volatility, instrument diversity)
• Market context:
  • Price volatility for instrument
  • Trading volume vs average

Processing:

1. ThetaRay ML model receives input features
2. Model outputs risk score (0-100) and confidence level
3. System combines rule-based score with ML score (weighted average: 60% ML, 40% rule)

Outputs:

• Final risk score (0-100)
• Risk category: Low (0-40), Medium (41-70), High (71-100)
• Model explainability: Top 3 contributing factors

Performance: Score generation within 5 seconds per alert

Fallback: If ML model unavailable, use rule-based score only (flagged for review)

FR-004: Alert Triage and Prioritisation

Description: System shall automatically categorise and prioritise alerts for analyst review

Inputs:

• Alert risk score (from FR-003)
• Current analyst workload
• Alert age

Processing:

1. Categorise alert by risk score:
   • High: Score >70 → Top of queue
   • Medium: Score 41-70 → Standard queue
   • Low: Score 0-40 → Review when capacity available
2. Within each category, order by:
   • Age (oldest first)
   • Instrument type (priority: equities > derivatives)

Outputs:

• Prioritised alert queue visible to analysts
• High-risk alerts highlighted in red
• SLA countdown timer displayed (High: 4 hours, Medium: 24 hours, Low: 72 hours)

Business Rules:

• High-risk alerts require immediate notification (email + dashboard popup)
• If alert breaches SLA, escalate to compliance manager automatically

FR-005: Actimize Integration

Description: System shall integrate with Actimize case management system for escalated alerts

Inputs:

• Escalated alert (from analyst investigation)
• Alert details, evidence, analyst comments

Processing:

1. Map surveillance alert fields to Actimize case fields
2. Call Actimize REST API to create case
3. Upload supporting documents (trade blotter, evidence package)
4. Link case ID back to surveillance alert

Outputs:

• Case created in Actimize
• Case ID stored in surveillance system
• Confirmation sent to analyst

Error Handling:

• API call fails → Retry 3 times with exponential backoff
• After 3 failures → Queue for manual creation, notify IT support

Performance: Case creation within 5 minutes of escalation decision

4. User Interface Requirements

UI-001: Analyst Dashboard

Description: Main screen for surveillance analysts to review and action alerts

Layout:

┌─────────────────────────────────────────────────────────────┐
│ TRADE SURVEILLANCE DASHBOARD                    [User: Sarah]│
├─────────────────────────────────────────────────────────────┤
│                                                               │
│ [High-Risk: 5] [Medium-Risk: 18] [Low-Risk: 47]              │
│                                                               │
│ ┌───────────────────────────────────────────────────────┐   │
│ │ PRIORITY QUEUE                                        │   │
│ ├────┬──────────┬─────────┬───────┬──────────┬─────────┤   │
│ │ !  │ Time     │ Trader  │ Rule  │ Risk     │ SLA     │   │
│ ├────┼──────────┼─────────┼───────┼──────────┼─────────┤   │
│ │ 🔴 │ 09:15:23 │ J.Smith │Layering│ 87 (HIGH)│ 3h 12m  │   │
│ │ 🔴 │ 09:23:45 │ M.Jones │Spoofing│ 78 (HIGH)│ 2h 54m  │   │
│ │ 🟡 │ 09:31:12 │ A.Brown │Wash    │ 65 (MED) │ 22h 18m │   │
│ │ ...│          │         │        │          │         │   │
│ └────┴──────────┴─────────┴───────┴──────────┴─────────┘   │
│                                                               │
│ [Filter: All Rules ▼] [Filter: All Desks ▼] [Search: ___]   │
└─────────────────────────────────────────────────────────────┘

Interactions:

• Click on alert row → Open alert detail screen
• Filter by risk level, rule type, desk, trader
• Search by trader name, instrument, alert ID

Acceptance Criteria:

• Dashboard loads within 2 seconds
• Auto-refreshes every 30 seconds
• Visual indicators (🔴/🟡/🟢) for risk level
• SLA countdown updates in real-time

UI-002: Alert Detail Screen

Description: Detailed view of single alert for investigation

Sections:

1. Alert Summary: Risk score, rule triggered, timestamp, trader, instrument
2. Trade Details: Full trade information, counterparty, venue
3. Evidence Package: Related trades, orders, price chart
4. Historical Context: Trader's past alerts, false positive rate
5. Decision Panel: Close as false positive / Escalate for investigation
6. Comment Box: Mandatory comment (min 50 characters)

Actions:

• [Close as False Positive] button
• [Escalate to Investigation] button
• [Request More Information] button (sends email to trader's manager)
• [Export PDF] button (for regulatory reporting)

Acceptance Criteria:

• All evidence loads within 3 seconds
• Comment box enforces 50-character minimum
• Decision cannot be submitted without comment
• PDF export includes full audit trail

5. Data Requirements

Trade Data Model

Alert Data Model

6. Integration Specifications

Integration INT-001: OMS Trade Feed

Source System: Fidessa OMS Integration Method: Kafka message queue Message Format: JSON Frequency: Real-time (streaming) Volume: ~10,000 messages/day (peak: 500/hour)

Sample Message:

{
  "tradeId": "TRD-20250115-00123",
  "instrument": "VOD.L",
  "quantity": 10000,
  "price": 125.50,
  "timestamp": "2025-01-15T09:15:23Z",
  "traderId": "TRAD001",
  "venue": "LSE",
  "counterpartyId": "CP-12345",
  "side": "BUY"
}

Error Handling:

• Invalid schema → Dead letter queue
• Duplicate tradeId → Idempotent processing (ignore duplicate)
• Missing required field → Reject and log error

Integration INT-002: Actimize Case Management

Target System: Actimize SAM Integration Method: REST API Authentication: OAuth 2.0 Frequency: On-demand (per escalation) Volume: ~100 cases/month

API Endpoint: POST /api/v2/cases Request Body:

{
  "caseType": "MARKET_ABUSE_INVESTIGATION",
  "priority": "HIGH",
  "subject": "Layering Alert - Trader J.Smith - VOD.L",
  "description": "...",
  "relatedAlerts": ["ALT-20250115-00456"],
  "assignedTo": "MLRO_TEAM"
}

Response:

{
  "caseId": "CASE-2025-00789",
  "status": "CREATED",
  "timestamp": "2025-01-15T10:30:00Z"
}

7. Non-Functional Requirements

NFR-001: Performance

• Alert generation latency: <1 minute (95th percentile)
• Dashboard load time: <2 seconds
• Search response time: <500ms
• ML scoring: <5 seconds per alert
• Actimize case creation: <5 minutes

NFR-002: Scalability

• Support 10,000 trades/day (current)
• Scale to 15,000 trades/day without re-architecture
• Support 5 concurrent analysts (current: 2)

NFR-003: Availability

• 99.5% uptime during trading hours (7am-7pm GMT, Monday-Friday)
• Planned maintenance outside trading hours only
• Automatic failover for critical components

NFR-004: Security

• Role-based access control (RBAC): Admin, Analyst, Read-Only
• All API calls authenticated via OAuth 2.0
• Sensitive data encrypted at rest (AES-256) and in transit (TLS 1.3)
• Audit logging of all user actions

NFR-005: Compliance

• Data retention: 7 years (regulatory requirement)
• Audit trail: All decisions logged with user ID, timestamp, IP address
• Immutable logs: No deletion or modification of historical data

Requirements Traceability Matrix

Change Control Process

1. Change Request: Stakeholder submits change request form
2. Impact Assessment: BA assesses impact on scope, timeline, budget
3. Approval: Project board approves/rejects change
4. Update Documents: BA updates BRD/FRD with version control
5. Communication: Change communicated to all stakeholders

Change Authority:

• Minor changes (<5 days effort): Project Manager
• Major changes (>5 days effort): Project Board
• Scope changes: Business Sponsor

Approval

Need Expert Support?

Writing requirements that actually drive successful delivery requires experience, discipline, and stakeholder management skills. If you need support with business analysis, requirements elicitation, or preventing project failures, contact our team for a consultation.

Template Version: 1.0 Last Updated: January 2025 Compatible With: BABOK, Agile, Waterfall, Hybrid methodologies License: Free for commercial use with attribution