Both follow the method I use on every project, understand first and then build: business rules are agreed and checked for conflicts before anyone designs a schema or writes code.
SYSTEMS / BUSINESS ANALYSIS
NordPay A/S
I find it more useful to show how I work than to list skills. This case study walks through a complete business analysis engagement, from a one-page problem statement to an MVP running in production, with every deliverable and what it concretely produced.
THE BRIEF
Danish payments fintech, ~150 employees
300+ daily transactions reconciled through Excel and email, with no single source of truth
~€22,000 per month in reconciliation errors and chargeback fees
A web-based transaction management platform integrated with the core banking ledger
No operational downtime · GDPR · €250K budget
MVP live in 10 weeks · 0 scope changes after sign-off
RESULTS
Illustrative outcomes for this fictional engagement, calculated the same way I would report real ones.
within 3 weeks of go-live
from 23 minutes to 4 minutes
across 3 sprints
the client had estimated 6 months
ROI payback in 12 months
from Sprint 1 to Sprint 3
HOW I WORK
Two phases, plus team management running throughout. Every step has a named deliverable and a concrete effect on the project. Select a step to jump to it.
Understand the problem before touching the solution.
Translate understanding into requirements and working software.
Governance that keeps scope and people aligned.
A one-page brief defining who is affected, what the problem is, and why it matters.
“NordPay loses €22K/month because ops staff reconcile transactions across 4 disconnected sources, creating settlement conflicts with no single source of truth.”
Outcome Approved by the CFO and CTO in Week 1, and used as the scope north star for the whole engagement.
The cost of keeping the manual process, compared with the cost of replacing it.
Outcome Approved the same day. The project went ahead with no further budget discussion.
Six interviews, some of them iterative, to map each stakeholder's needs and influence on the project.
Key find Merchant Support revealed that merchants called every day to ask about settlement status. This was not in the original brief, and became the Merchant Portal feature.
26 terms defined and agreed across departments in Week 2.
Critical find “Transaction” meant three different things to Risk, Finance, and Operations. Resolving it before the first wireframe prevented about 3 weeks of back-and-forth in development.
Three personas with day-in-the-life scenarios, describing each user's goals, behaviour, and frustrations.
GoalProcess transactions fast
FrustrationSwitching between 4 systems per transaction
GoalReal-time settlement visibility
FrustrationNo dashboard, everything is in email
GoalKnow settlement status
FrustrationCalling to chase confirmations
Journeys mapped for all three personas across the transaction lifecycle: workflows, touchpoints, pain points, and information needs.
Key find Two touchpoints in the existing process had no digital equivalent. They became requirements for the Fraud Analyst Console and the Merchant Portal before wireframing began.
The current transaction process was mapped step by step to find unnecessary steps and manual dependencies, then redesigned and validated with stakeholders.
View full size ↗
8 screen flows built in Figma over 3 days, then validated in a 90-minute stakeholder walkthrough so everyone shared the same picture of the solution.
Ops manager persona · real-time view of transactions, settlements, held items, and ledger sync.
Reconciliation analyst persona · business rules enforced live: an amount above 90% of the merchant's fraud threshold is held for review.
Fraud analyst · every held transaction in one place, with the reason it was held and a one-click decision.
Outcome 2 minor label changes and zero functional changes in the walkthrough. Scope locked.
11 assumptions and constraints documented and tracked.
Most impactful The core banking ledger API is rate-limited to 100 calls per minute. This shaped the entire sync architecture (a 15-minute asynchronous settlement queue), and was caught here rather than in Sprint 3.
17 rules captured before the schema was designed, not after something broke. Two examples:
A merchant cannot exist twice under two internal IDs. Every reference points to one real merchant.
A transaction above 90% of the merchant's fraud threshold, or with unusual activity, is held for a fraud analyst instead of being approved automatically.
Outcome Agreeing the rules up front prevented 3 architecture debates later in development.
Try it yourself. Check rules like the fraud hold for contradictions in the Requirements Verifier.
View full size ↗
Outcome The “Merchant” entity existed twice, in core banking and in the CRM. It was resolved into one canonical merchant before the database schema was created.
19 requirements covering how the system must behave, not just what it does.
<2s page load · <500ms API · 60 concurrent users
99.5% SLA · graceful degradation when the ledger is offline
Role-based access (4 levels) · encryption at rest and in transit · full audit log
GDPR · PSD2 strong customer authentication · DORA operational resilience · Danish data residency · PII and PCI fields flagged in the data model
The wireframes became a working prototype that real analysts could click through, not just review.
Each user action was specified as trigger → decision → outcome, so developers could build directly from it.
Key find Bulk settlement import was critical for analysts but missing from scope. It was added as a Must-Have and approved within 24 hours.
The validated prototype pages became a prioritised, sprint-ready plan: 5 epics and 51 user stories. The proof of concept covered core functionality only.
MoSCoW · Must · Should · Could · Won't
questions per story after weekly refinement, with velocity up 38%
by keeping Should and Could items out of the MVP
“An analyst at NordPay can create and submit a transaction digitally, without touching Excel.”
| Epic | PoC feature | User story |
|---|---|---|
| Transaction intake | New transaction · Validation | Create a single transaction · Hold a transaction above the fraud threshold |
| Exception management | Flag | View all flagged transactions in one place |
| Integrations | Ledger sync | Sync confirmed transactions to the core banking ledger |
What “done” means for each story: testable, unambiguous, and agreed before development starts.
As a reconciliation analyst, I want to create a single transaction with automatic fraud-threshold validation, so that only risky transactions wait for review.
Acceptance criteria · within thresholdEdge cases 34 documented. The most impactful: if the ledger times out, transactions wait in a 15-minute local queue with the sync status shown, and no analyst action is needed.
Ratified by development, QA, and the business
Sign-off Stakeholders signed off in Week 7, followed by zero scope changes in Sprints 1–3.
CONTINUOUS · TEAM MANAGEMENT
A 30-minute RAG status for the CFO and CTO. 4 change requests logged: 2 approved, 2 deferred.
Making Finance Consulted rather than Accountable on the data model eliminated a 3-week back-and-forth.
Bulk settlement import: a 2-day impact assessed and approved within 24 hours, with zero sprint disruption.
Steering, refinement, stand-up, and sprint review in just
2 h 45 min / weekDELIVERY TIMELINE
NPV model approved by CFO and CTO · 3 stakeholder interviews completed
3 remaining interviews · 3 personas finalised · 26-term glossary, “transaction” ambiguity resolved
As-is / to-be mapped (11 → 3 steps) · 3 journey maps · 8 screen flows in Figma
6 entities · 17 business rules · 19 NFRs · stakeholder walkthrough, scope baselined
9 pages · 38 user actions · 5 usability sessions · bulk settlement import added as Must-Have
5 epics · MoSCoW applied · 51 user stories · sign-off at the end of Week 7
All acceptance criteria in Given/When/Then · 34 edge cases · 6-point DoD ratified by dev, QA, and compliance
Transaction intake live in production · Sprints 2–4 planned · 0 scope changes after sign-off
SKILLS REFERENCE
BEYOND THE PROOF OF CONCEPT
| Epic | Key features | User stories |
|---|---|---|
| Transaction intake | New transaction · Bulk settlement import · Validation | Create a single transaction · Import a merchant settlement batch from Excel · Hold a transaction above the fraud threshold |
| Exception management | Flag · Resolve · Escalate | View all flagged transactions in one place · Approve or reject a held transaction · Escalate a case to Risk & Compliance |
| Merchant portal | Settlement status · Notifications | Check settlement status without calling · Receive a settlement confirmation automatically |
| Reporting | Daily reconciliation · Audit export | Get the daily reconciliation report automatically · Export the audit log for a compliance review |
| Integrations | Ledger sync · Core banking KYC · Email | Sync confirmed transactions to the ledger · Check merchant KYC status automatically · Send email notifications |
SYSTEMS / BUSINESS ANALYSIS / REQUIREMENTS VERIFIER
Write business rules in plain English. The verifier turns them into a formal model, checks every relevant case for contradictions and for rules that can never apply, and writes a Lean 4 proof for each finding.
Must / cannot / are always become rules for every record. Can / may describe records that must be allowed to exist.