Product Requirements Document

[Product or Feature Name]

Template by Timileyin Abdulsalam · Product Manager, Payments & Fintech · timi4real1.github.io

How to use this template: text in [brackets] is a placeholder. Grey italic rows are worked examples drawn from a sanitized virtual account product; replace them with your own content. Delete the italic guidance notes before circulating.

Email me for the editable Word version

Document Control

Version	Date	Author	Summary of changes
0.1	[date]	[name]	First draft for internal review
1.0	[date]	[name]	Approved for build after stakeholder sign-off

Field	Value
Status	[Draft / In review / Approved / In build]
Product owner	[name]
Stakeholders	[Engineering lead, Design, Compliance, Operations, Business owner]
Target release	[quarter or date]

1. Background & Context

Two or three paragraphs. Where does this product sit in the business? What exists today? Why now?

[Describe the current state, the business context, and the trigger for this initiative.]

Example: The bank currently issues static virtual accounts through a legacy service with no expiry control. Partners have requested dynamic accounts with configurable time-to-live so they can reconcile one-off collections without manual matching.

2. Problem Statement

One sharp paragraph. Whose problem, what problem, what it costs them today. If you cannot write this section clearly, the product is not ready to spec.

[User group] cannot [job to be done] because [constraint]. Today this costs them [time, money, or risk].

3. Goals & Success Metrics

Every goal needs a measurable target and a data source. If it cannot be measured from the platform, it is a wish, not a goal.

Goal	Metric	Target	Source
[Business goal]	[Measurable indicator]	[Number]	[Dashboard / SQL]
Reduce reconciliation effort for partners	% of collections auto-matched	95%	Settlement DB

Non-goals

What this release deliberately does not do. This is the strongest defence against scope creep.

[Out-of-scope item and one line on why]

4. Users & Actors

Actor	Description	Key need
[Actor]	[Who they are]	[What they need from this product]
Partner developer	Integrates the API on behalf of a fintech	Clear specs, predictable errors, fast certification

5. User Stories & Acceptance Criteria

Story format: As a [actor], I want [capability], so that [outcome]. Acceptance criteria are testable statements; QA writes cases directly from them.

ID	User story	Acceptance criteria
US-01	[As a ..., I want ..., so that ...]	[Given / when / then statements]
US-02	As a partner developer, I want to set an expiry when creating a dynamic virtual account, so that unused accounts close automatically.	Given a valid request with expiry_minutes between 5 and 1440, when the account is created, then it rejects payments after expiry and emits an account.expired webhook.

6. Functional Requirements

Numbered, prioritised with MoSCoW. Each requirement is one testable behaviour, not a paragraph of intentions.

ID	Requirement	Priority	Story
FR-01	[The system shall ...]	Must	US-01
FR-02	The system shall generate a unique NUBAN within 2 seconds of a valid create request.	Must	US-02

7. User Flows

Insert flow diagrams here (happy path plus the two most important failure paths). One diagram per core journey. Tools: Figma, Whimsical, or draw.io.

[Flow 1: e.g. Account creation and payment happy path]

[Flow 2: e.g. Payment after expiry - rejection and webhook]

8. API Specification

The contract engineering builds from and partners integrate against. Full request/response samples live in the Postman collection; this section holds the summary table and rules.

Method	Endpoint	Purpose	Auth
[VERB]	[/path]	[What it does]	[Scheme]
POST	/v1/virtual-accounts	Create static or dynamic virtual account	OAuth 2.0

Error handling

[Error model: codes, structure, retry guidance. Example: all errors return a machine-readable code, a human message, and a reference ID.]

Webhooks & events

[Event name, trigger, payload summary, retry policy]

9. Non-Functional Requirements

Category	Requirement
Performance	[e.g. P95 latency under 500ms at 100 TPS]
Availability	[e.g. 99.9% monthly uptime; degradation plan]
Security	[e.g. encryption at rest and in transit, key rotation, least privilege]
Compliance	[e.g. CBN guidelines, NDPR data residency, KYC tier limits]
Auditability	[e.g. every state change logged with actor and timestamp]

10. Dependencies & Assumptions

[Dependency: system, team, or third party this build relies on]
[Assumption: what we are treating as true; flag the risk if it is not]

11. Rollout Plan

Phase	Scope	Exit criteria
UAT	[Internal testing scope]	[e.g. zero Sev-1 defects]
Pilot	[Limited partners or volume]	[e.g. 2 partners certified, error rate under 0.5%]
GA	[Full availability]	[e.g. monitoring and support runbook live]

12. Risks & Mitigations

Risk	Likelihood	Impact	Mitigation
[What could go wrong]	[H/M/L]	[H/M/L]	[What we do about it]

13. Open Questions

#	Question	Owner	Due
1	[Unresolved decision blocking build]	[name]	[date]

Appendix: Glossary

Define every acronym once. Partners and new joiners read this first.

Term	Definition
[Term]	[Plain-language definition]
NUBAN	Nigeria Uniform Bank Account Number, the 10-digit standard account format.

Built from the PRDs I write at a CBN-licensed payment service bank, sanitised for public sharing. If you need a PRD, an API specification, or product discovery for a fintech build, email me or reach me on WhatsApp.