⏱ 14 min read
FROM LAW TO CODE:
Managing Requirements End-to-End in a FinTech & Banking Organisation
A practical guide using Sparx Enterprise Architect Sparx EA best practices
Introduction
Running a bank or a FinTech is, at its core, an exercise in managing obligations. Regulators write laws. Supervisors translate those laws into rulebooks. Executives translate rulebooks into programmes. Engineers translate programmes into code. Somewhere between Parliament and the production environment, the thread gets lost — and that is exactly when regulators come knocking. enterprise cloud architecture patterns
This article walks through a requirements management model built in Sparx Enterprise Architect (EA) that shows how a financial institution can trace every single system capability back to the law that created the obligation in the first place. The model covers five regulatory regimes that any bank operating in the UK or EU has to navigate: the Anti-Money Laundering Act, GDPR, PSD2, Basel III, and the FCA Consumer Duty. free Sparx EA maturity assessment
Rather than treating requirements as sticky notes on a sprint board, this approach treats them as first-class modelling artifacts — connected, versioned, and traceable. Let us walk through each diagram in the model and explain what it tells us and why it matters.
1. The Big Picture: A Requirements Landscape
Before diving into individual diagrams, it helps to see the whole model at a glance. The overview diagram below is the entry point — think of it as a map of the territory. It shows six packages and the relationships between them, giving any stakeholder an instant orientation.
What you can see immediately is that the model is layered. On the left sit the Laws and Regulations — the source of truth for every obligation. In the middle, Business Requirements translate those legal obligations into organisational commitments. From there, the model fans out into Functional Requirements (what the system must do), Non-Functional Requirements (how well it must do it), and User Stories (how teams will build it). Stakeholders appear as actors who own or approve requirements at each layer. hybrid cloud architecture
Notice that even the overview diagram is generated by the script — it is not a hand-drawn slide. This means it stays current as the model evolves, and any stakeholder opening the project in EA sees the same consistent view.
2. Where It All Starts: Regulatory Traceability
The most important diagram in any compliance-driven requirements model is the one that connects laws to business commitments. Regulators often ask: "Show me the requirement that implements Article X of Directive Y." Without explicit traceability, answering that question takes weeks of archaeology through SharePoint folders. With this model, the answer is two clicks away. multi-cloud architecture strategy
Five pieces of legislation sit at the bottom of the diagram — note the annotation "(from Laws and Regulations)" under each one, which tells EA readers that these elements live in a different package but are being cross-referenced here. This is a deliberate modelling choice: you define a law once and reference it everywhere it has an impact, rather than duplicating it.
The dashed arrows are UML Realisation connectors stereotyped as «derives». They flow upward from law to business requirement, reflecting the direction of obligation: the law creates the requirement, not the other way around. Here is what each law derives:
- LAW001 — Anti-Money Laundering Act → BR001 Know Your Customer Programme + BR002 Transaction Monitoring
- LAW002 — GDPR and Data Protection Act → BR003 Data Privacy and Consent Management
- LAW003 — PSD2 Payment Services Directive → BR004 Strong Customer Authentication + BR005 Open Banking API Platform
- LAW004 — Basel III Capital Requirements → BR006 Capital Adequacy Reporting
- LAW005 — FCA Consumer Duty → BR007 Consumer Outcome Monitoring
The colour bar on each requirement element indicates its approval status — a convention borrowed from the Sparx EA example model. Green means Validated (reviewed and confirmed against the source), Blue means Approved (signed off by a named owner), and Yellow means Proposed (still under discussion). The laws themselves are all Approved, because they are statute — they are not going anywhere.
3. KYC & Customer Onboarding: Decomposing a Business Requirement
BR001 — Know Your Customer — is probably the most operationally complex business requirement a bank faces. It is not one thing; it is a programme consisting of several interlocking capabilities. The diagram below decomposes BR001 into six functional requirements using UML Aggregation — the diamond connector — to show the parent-child relationship.
The six functional requirements that together constitute a KYC programme are:
- FR001 — Identity Verification: automated OCR and biometric liveness checks on identity documents in real-time.
- FR002 — Beneficial Ownership Check: identify all owners holding 25% or more control for corporate customers.
- FR003 — PEP and Sanctions Screening: screen against politically exposed persons lists and OFAC/UN/EU sanctions databases.
- FR004 — Customer Risk Scoring: composite Low/Medium/High risk score that drives workflow branching.
- FR005 — Enhanced Due Diligence Workflow: mandatory senior management approval for High-risk customers.
- FR006 — KYC Audit Trail: immutable log of all decisions retained for five years.
Notice that BR001 is shown with the annotation "(from Business Requirements)" beneath it. This is because the diagram lives inside the KYC and Onboarding sub-package of Functional Requirements, but BR001 is defined in the Business Requirements package. EA resolves cross-package references automatically, keeping the model consistent without duplication.
The aggregation diamond faces the parent (BR001), meaning the parent is the whole and the children are parts of it. This is semantically correct: if BR001 is ever removed from scope, EA's impact analysis will immediately flag all six FR children as potentially orphaned. That is the power of modelling relationships rather than just writing lists.
4. Payments & Transaction Monitoring: Where PSD2 Meets AML
PSD2 and the AML Act both touch the payments domain, but from different angles. The AML Act requires surveillance of transactions after they occur; PSD2 requires authentication controls before a payment is authorised. The diagram below captures both threads and shows how three separate business requirements each decompose into their own functional requirements.
What is particularly interesting here is the way the diagram reveals a potential integration dependency that would not be visible in a flat requirements spreadsheet. FR007 (Real-Time Transaction Screening) and FR010 (SCA Enforcement on Payments) are both in the payments processing pipeline. The engineering team working on the payment gateway needs to implement both — not as separate features but as a coordinated control sequence. The model makes this visible.
The SAR Filing requirement (FR009) is worth calling out explicitly. It requires the compliance case management system to integrate directly with the NCA's ELMER electronic reporting system. This is an external dependency that needs a formal interface specification — exactly the kind of detail that tends to surface late in a project when requirements are captured informally.
5. Non-Functional Requirements: The Quality Obligations
Regulators do not just care about what a system does — they care deeply about how reliably and securely it does it. The PRA and FCA have specific operational resilience requirements. GDPR mandates technical controls around data security. The NFR diagram captures these quality obligations in four groups.
The diagram uses EA package boundary elements as visual grouping containers. Each package lists its requirements in the standard EA format — the checkbox icon indicates they are Requirement elements, and the + symbol indicates they can be expanded. The four domains are:
- Security (NFR001–NFR003): AES-256 encryption, annual CREST penetration testing, and just-in-time privileged access control.
- Performance (NFR004–NFR005): Payment gateway latency under 200ms at p95 for 5,000 TPS; KYC service throughput of 1,000 concurrent sessions.
- Availability and Resilience (NFR006–NFR007): 99.99% monthly uptime with RTO under 30 minutes and RPO under 5 minutes; semi-annual DR rehearsals.
- Regulatory Compliance (NFR008–NFR009): Immutable 7-year audit logs per FCA SYSC; zero-tolerance SLA for regulatory report submissions.
NFRs in this model are connected to the business requirements they constrain via «refine» dependency connectors. For example, NFR001 (Data Encryption) refines BR001 (KYC Programme) because KYC involves processing highly sensitive personal data. This linkage means that if the KYC scope changes, the security requirement is flagged for review as well.
6. The Traceability Diagram: The Regulator's View
If you had to show a regulator one diagram and one diagram only, this would be it. The AML Law to KYC System Features diagram shows the complete chain of reasoning from a specific piece of legislation all the way down to an Agile user story and the person accountable for it. ISO/IEC 29148 and the FCA's SYSC 13 guidance both require firms to demonstrate this kind of traceability, but most firms demonstrate it through narrative documents rather than live models.
Reading the diagram from bottom to top follows the derivation chain:
- LAW001 (Anti-Money Laundering Act) is the legislative source.
- A «derives» realisation connector flows from LAW001 to BR001 (KYC Programme) — the law creates the obligation.
- BR001 aggregates FR001 (Identity Verification), FR003 (PEP & Sanctions Screening), and FR004 (Customer Risk Scoring) — the business requirement decomposes into system capabilities.
- A «trace» dependency connects FR004 and FR001 to US001 (KYC Review User Story) — the agile team implements the capability.
- US001 is associated to the Compliance Analyst — the person who owns the user story and accepts the feature.
This chain has an important property: it is bidirectional. If the AML Act is amended — which happens periodically as FATF guidance evolves — an analyst can open LAW001 in EA, right-click, and select Traceability to see every downstream element affected. In a medium-sized bank with thousands of requirements, this can mean the difference between a controlled change programme and a chaotic scramble.
7. User Stories: Bridging Compliance and Agile Delivery
One of the most persistent tensions in regulated industries is the mismatch between compliance timescales (often annual regulatory cycles) and Agile delivery timescales (two-week sprints). The user stories diagram is the bridge between those two worlds.
The four user stories cover the core compliance journeys a bank needs to support:
- US001 — KYC Review User Story: As a Compliance Analyst I want to review a customer's KYC risk score and supporting evidence so that I can make an informed onboarding decision.
- US002 — SAR Filing User Story: As an MLRO I want to file a Suspicious Activity Report directly from the transaction alert so that I meet the 7-day statutory reporting deadline.
- US003 — Consent Management User Story: As a Customer I want to view and update my data processing consents from the mobile app so that I can exercise my GDPR rights easily.
- US004 — Biometric Payment Auth User Story: As a Customer I want to authenticate once using biometrics to initiate a payment so that I comply with SCA requirements without friction.
In Sparx EA, user stories are modelled as Use Cases with the «User Story» stereotype. This lets them appear in Use Case diagrams alongside actor associations, while also carrying Requirements-style attributes like Volatility and Priority as tagged values. The EA element compartments — when enabled — show these tags directly on the diagram element, giving sprint planners an at-a-glance priority view without opening the properties sheet.
Each story is associated with a named actor from the Stakeholders package — the person who will validate the delivered feature. This makes the acceptance criterion chain explicit: the Compliance Analyst who owns US001 is also the person who must sign off that FR001 has been correctly implemented before it can be linked as Implemented.
8. How the Script Works
Everything shown in this article was generated by a single JavaScript file run inside Sparx EA's built-in scripting engine. No manual element creation, no drag-and-drop, no formatting by hand. The script uses EA's COM automation API to create packages, elements, connectors and diagram objects programmatically.
The key design decisions in the script are worth understanding:
Elements before diagrams
All requirement elements and connectors are created first. Diagrams are created last and simply reference existing elements by ElementID. This means every relationship exists in the repository regardless of which diagram is open — the diagrams are views onto the model, not the model itself.
Tagged values carry the metadata
Each requirement element carries tagged values for Requirement ID, Author, and Difficulty, in addition to the built-in Status and Priority properties. These tagged values are what power EA's Specification Manager and Dashboard views — the pie chart of requirements by priority shown in the original Sparx example is driven by these same tags.
Connector stereotypes encode semantics
Three connector types carry specific meanings in this model: «derives» (law creates obligation), Aggregation diamond (whole-part decomposition), and «trace» (implementation link). Using the correct UML semantics means EA's built-in Traceability window and Impact Analysis features work correctly out of the box.
Safe for re-runs with guarded error handling
Every connector creation is wrapped in a try-catch block. If a single relationship fails — for example, because two elements are in packages that the current user does not have write access to — the script continues building the rest of the model and logs a warning rather than aborting the entire run.
9. Extending the Model
The model described here covers five regulatory regimes and fourteen functional requirements. A real bank will have hundreds of regulations and thousands of requirements. The same script structure scales to that level — the functions are reusable, and adding a new regulation is a matter of calling createReq() with the right parameters and wiring up the link() calls.
There are several natural extensions worth considering:
- Test Cases: EA supports Test elements that can be linked to requirements via «verify» connectors, completing the V-model from law to test evidence.
- Risk Elements: EA's Risk stereotype can be used to model regulatory risks linked to business requirements, feeding into a risk register view.
- Change Requests: EA supports Change elements that can be used to capture proposed requirement changes and their downstream impact before acceptance.
- Roadmap Diagrams: EA's Roadmap diagram type can show which requirements are planned for which release, giving compliance teams a delivery timeline view.
- Specification Manager: EA's built-in Specification Manager provides a Word-like filtered view of all requirements, useful for regulatory submissions.
Conclusion
Requirements management in a regulated financial institution is not a documentation exercise — it is a risk management discipline. The difference between a requirements spreadsheet and a requirements model is the difference between a list of obligations and a network of obligations. Networks can be traversed, queried, and impact-analysed. Lists cannot.
The Sparx EA model shown in this article demonstrates that building that network does not require a large manual modelling effort. A script of under 400 lines creates a fully connected, seven-diagram requirements model covering the most significant regulatory regimes a UK/EU bank faces — in seconds. The hard part is not the tooling; it is agreeing on the requirements in the first place. But once you have agreed, the model gives you a living record of those agreements that stays current as the regulatory landscape evolves.
For expert guidance on requirements management with Sparx EA, explore our Sparx EA training, TOGAF training, and consulting services. Get in touch.
Frequently Asked Questions
What is Sparx Enterprise Architect used for?
Sparx Enterprise Architect (Sparx EA) is a comprehensive UML, ArchiMate, BPMN, and SysML modeling tool used for enterprise architecture, software design, requirements management, and system modeling. It supports the full architecture lifecycle from strategy through implementation.
How does Sparx EA support ArchiMate modeling?
Sparx EA natively supports ArchiMate 3.x notation through built-in MDG Technology. Architects can model all three ArchiMate layers, create viewpoints, add tagged values, trace relationships across elements, and publish HTML reports — making it one of the most popular tools for enterprise ArchiMate modeling.
What are the benefits of a centralised Sparx EA repository?
A centralised SQL Server or PostgreSQL repository enables concurrent multi-user access, package-level security, version baselines, and governance controls. It transforms Sparx EA from an individual diagramming tool into an organisation-wide architecture knowledge base.