How to Run a FinTech Discovery Phase: Requirements, Deliverables and Checklist

A clear feature list is not enough to estimate a FinTech product. The team also needs to know when balances change, how failed payments are handled and which decisions depend on external providers. Unanswered questions can lead to redesigns, delays or incorrect money movements.

This guide walks through five practical steps of the software development discovery phase, using a digital wallet example to show how product decisions become development requirements. It also explains how SDK.finance, a fintech software development company with 15+ years of industry experience, helps turn those requirements into financial software through custom development and reusable components.

What is a FinTech discovery phase?

A FinTech discovery phase is the research and planning stage before developing a financial product, such as a digital wallet or payment app. The team defines who the product is for, what it needs to do and how it can be built.

In FinTech, a user action connects to financial records and often an external service. A withdrawal button involves eligibility checks, balance changes, provider responses and a way to resolve exceptions. Discovery establishes how these parts work together and who owns each decision.

The outcome is a practical next step: build the agreed scope, test a specific uncertainty, revise the proposal or pause affected work. Discovery reduces uncertainty; it does not make every assumption true or replace launch-readiness checks.

Discovery, PoC and MVP: different questions

Product discovery asks whether the product solves a meaningful user problem. Software discovery defines the implementation scope, technical feasibility and assumptions behind the delivery plan. These activities overlap, but a technically feasible product still needs evidence of user demand.

• Discovery defines what to build, why it is needed and how to approach development. Its output is an agreed scope, requirements and a delivery plan.
• A proof of concept (PoC) tests whether a specific technical approach can work. Its output is evidence from a focused experiment, rather than a product ready for users.
• A minimum viable product (MVP) is a working first version with enough functionality for real users to try. It helps the team test the product’s value and decide what to improve next.

Use a PoC when a focused experiment can resolve a question that otherwise prevents a reliable design or estimate.

Discovery phase deliverables: what should the team produce?

The discovery pack should help reviewers make decisions without reconstructing workshop discussions. Its documents can live in one workspace, provided their responsibilities and relationships remain clear.

A requirement describes the behaviour needed; a backlog item describes the work to deliver it. Keep them linked so changes to a product rule can be traced into design, testing and estimation.

How to run a software development discovery phase in five steps

Before the first workshop, gather the product hypothesis, target markets and currencies, existing workflows, provider documentation and sample reports. Modernisation projects also need current architecture, data-quality findings and migration constraints. Record missing inputs as questions with owners.

One person may cover several roles, but each decision needs an accountable reviewer. Invite security and compliance specialists where their input affects the operating model, controls or implementation.

Step 1: Agree the user problem and first-release scope

Who participates: Product owner, business analyst and UX researcher or designer, with relevant business stakeholders.

What they do: Separate evidence from assumptions. Identify the target user, the problem and the smallest complete journey worth delivering. Define the launch market, currencies, success measures and explicit exclusions.

Use research to test the problem before refining features. If unclear payment status appears to generate support requests, review support evidence and ask users how they distinguish a pending payment from a failed one. The findings may favour clearer messages and support guidance over another payment feature. Record how the evidence changes the release priorities.

Document the operating model alongside the product scope: who provides regulated services, who holds or moves external funds and which responsibilities belong to the software operator or partner. Have the relevant specialists review unresolved questions before they become design assumptions.

Output: A product brief and scope baseline that explain who the release serves, what it includes and what evidence still needs collecting.

Step 2: Map user journeys and money flows

Who participates: Business analyst, product owner, architect, UX designer and finance or payment-operations representatives.

What they do: Walk through each journey from the user action to its financial outcome. For every transition, identify the initiating event, the system updating the balance and the evidence that permits the next step.

Cover rejected requests, insufficient funds, delayed confirmations and unknown provider outcomes as well as successful payments. Ask operations to demonstrate how an unresolved case would be investigated and what information support staff would need.

Keep three questions separate: has the transaction completed, has a provider message arrived, and has external settlement occurred? A duplicate notification is a communication event, not a new payment.

Sketch or prototype the important customer-facing states. Check whether users understand a pending or failed transaction, know what happens next and can find help without submitting another payment.

Output: Journey and money-flow maps with balance effects, completion rules, customer messages and exception owners.

Step 3: Write requirements that can be tested

Who participates: Business analyst, QA, architect and the product or operational owner responsible for each rule.

What they do: Replace general promises with observable outcomes. Instead of “payments must be reliable”, specify the expected result when a confirmation arrives twice or a request exceeds the available balance.

Write acceptance criteria as a starting condition, an action or event, and the expected result. Include relevant rejection and interruption cases. Assign requirement IDs and reviewers, then check that customer-facing behaviour agrees with the accounting effect.

Define non-functional requirements with a target, measurement method and owner:

• Performance: transaction mix, peak load, test environment and latency percentile.
• Recovery: acceptable disruption and data loss, plus a restore or failover test.
• Monitoring: detection, escalation and ownership of unresolved transactions.
• Access and audit: permitted actions, denied actions and retained evidence.
• Data retention: rules by data category, reviewed with the relevant specialists.

The OWASP Application Security Verification Standard can support security requirements. Select the applicable requirements and version; using a checklist does not establish compliance.

For recovery requirements, verify that transaction records remain consistent after a restart or failover. Define the environment and workload for every test so a successful demonstration is not mistaken for evidence under production conditions.

Output: Requirements and acceptance criteria that developers can interpret and QA can verify, with unresolved targets clearly identified.

Step 4: Assess platform fit and provider dependencies

Who participates: Solution architect, integration owner and relevant product, finance, security and compliance reviewers.

What they do: Compare the required behaviour with the proposed software, not just its feature names. A platform may support transfers but need configuration or custom work for a particular approval rule, limit or exception.

Classify requirements as standard capability, configuration, custom development, external-provider dependency or unknown. A requirement may span several categories. Record the applicable version and evidence, such as documentation, a demonstration, a configuration review or a test.

For providers, check supported markets and currencies, contracted services, credentials, sandbox access, APIs, callback security, status queries and reports. Assign separate owners to commercial onboarding and technical integration. A successful sandbox call does not prove production access or permission to offer a service in every market.

Use a targeted PoC when an unanswered question could change the architecture. Define the test, expected evidence and decision owner before starting it.

Make the classification concrete. An internal transfer may be a standard-capability candidate, product-specific fees may be configuration, and a bespoke support approval may require custom development. A payout provider introduces an external dependency. These are starting hypotheses for assessment, not commitments about a particular platform.

Output: A fit-gap assessment and dependency map showing reusable functionality, additional work and technical questions to resolve.

Step 5: Review the pack and agree what happens next

Who participates: Product owner, delivery lead, architect and the specialists accountable for outstanding decisions.

What they do: Check that the scope, journeys, requirements and estimate describe the same product. Include configuration, custom development, integrations, exception handling, testing and operational work in the backlog.

Review each work package using three statuses:

• Approved: sufficient evidence supports the agreed work, and reviewers accept the remaining risks.
• Conditional: work may proceed only within stated boundaries while a named action resolves an open question.
• Blocked: a prerequisite prevents the affected work from starting.

Record the decision, its date, owner and supporting evidence. Give each open item a closure condition. Choose whether to proceed, run a PoC, revise scope or pause affected work; independent work can continue where its own assumptions remain valid.

Output: A versioned delivery decision, prioritised backlog and estimate basis. Revisit them when requirements, provider capabilities or operating constraints change.

FinTech discovery in practice: a digital wallet example

Consider a fictional wallet in US dollars (USD). Users A and B both start with zero balances. The first release supports top-ups, internal transfers, withdrawals, transaction history and operational exception handling. It excludes fees, FX, cards, cross-border payments, credit and migration.

These are illustrative design choices, not a description of a particular SDK.finance configuration. Using USD does not determine the launch jurisdiction or establish permission to provide financial services.

Define the boundaries first

Map the customer interface, transaction platform, accounting component and external payment or payout provider. Identify the authoritative record for transaction status and balance, plus the external evidence needed for reconciliation.

The product owner approves eligibility and scope; finance and operations approve balance, posting and reversal policies; the architect assesses technical fit; and the integration owner verifies provider behaviour. Include support staff who will explain unresolved transactions to users.

Before implementation, agree currency precision, fees, limits, refunds and funds-availability rules. The no-fee example below makes the flow easier to follow, but a real product needs explicit decisions on each of these points.

Follow $100 through the wallet

1. A tops up $100. After the qualifying provider confirmation, A has $100 available and B has $0. The credit follows the agreed funds-availability policy. Confirmation and external settlement are separate events; allowing spending before settlement may create exposure that discovery must assess.

2. A transfers $30 to B. The system records the sender’s debit and recipient’s credit consistently. A has $70 available and B has $30. This internal transfer requires no external bank movement in the example.

3. B requests a $20 withdrawal. The wallet reserves $20 while the payout is pending. B has $10 available and $20 reserved; A still has $70. Product and accounting owners must agree how the reservation is represented.

The following rows are alternative outcomes of that withdrawal, not consecutive steps.

If the payout outcome is unknown, B’s $20 remains reserved and the available balance stays at $10 until the outcome is established.

Finance matches external top-ups and payouts against provider reports or bank statements using references, amounts, currencies and timestamps. The internal transfer retains its own balanced records and audit trail; it needs no separate external settlement entry. Completed payouts still need reconciliation and a process for later adjustments.

Define states users and operations can understand

Pending means the operation has started but has not met its completion conditions. Completed means the journey-specific conditions are met and the required internal records are consistent. Failed means validation rejected the request before execution or reliable evidence confirms non-execution.

An unknown outcome may appear as pending to the customer while operations tracks the uncertainty separately.

For each state, specify the customer message, available actions, balance effect, escalation deadline and responsible team. Test whether users understand when to wait and when to contact support.

Wallet discovery template: requirements and decisions

The following compact template connects the brief, requirements and open decisions. The identifiers belong in the working records so the team can trace changes without filling the main narrative with cross-references.

• Product objective: Eligible users can add USD, transfer internally and withdraw while seeing a clear transaction status.
• User hypothesis: Clear pending-state information helps users decide whether to wait or contact support. Validate this through research.
• Scope and policies: Use the first-release boundaries and balance rules defined in the money-flow example above.
• Open prerequisites: Approved launch market and operating model; confirmation of the qualifying top-up event, payout recovery mechanism and reconciliation report fields.

Idempotency means repeating an operation does not create an additional financial effect under its defined conditions. Do not assume that a provider’s protection covers every retry or remains valid indefinitely.

Risk R-01: Recovery could duplicate a payout. Owner: integration owner. Evidence: the recovery test below.

Assumption A-01: Provider reports expose a usable matching reference. Finance checks an actual report sample.

Decision D-01: FR-03 remains blocked until the recovery test addresses R-01.

Keep these records distinguishable even if they share one document. Add the evidence, review date and current owner as discovery progresses.

SRS example: handling an uncertain withdrawal

• Trigger: An eligible user requests a withdrawal under the approved balance, fee and limit rules. The provider returns no definitive response within the configured timeout.
• System response: Retain the original request reference and agreed funds reservation. Show a pending outcome. Follow the provider’s documented status-query or idempotent-retry mechanism before considering a separate payout attempt.
• Operational fallback: If automated resolution is exhausted, assign the case to an authorised operations reviewer. Define the escalation deadline, permitted manual actions and responsibility for user updates. The deadline itself does not establish failure or justify releasing funds.
• Audit evidence: Retain the internal request ID, provider reference where available, timestamps, status-check attempts and authorised operational actions.
• Provider dependency: Confirm the lookup contract and the scope and expiry of idempotency protection.

Test the uncertainty, then estimate the work

Reproduce the scenario in which the provider accepts a withdrawal but the application receives no definitive response. The integration owner runs the recovery procedure in a controlled environment and retains the provider and internal records.

Check that recovery causes no additional payout and that transaction history, balance changes and manual actions match the provider outcome. Also test delayed confirmation and exhausted automated resolution. In this illustrative example, that validation is still pending.

Use the findings to estimate the implementation and testing needed to meet the SRS. Include operational handling and reconciliation work, such as report mapping, access controls and unmatched-item review.

Record the limits of the test evidence and any outstanding production access or contractual dependencies separately in the estimate.

Estimate the complete work, including configuration or coding, integration, testing and review. A new currency remains outside this release; adding one requires reassessing money flows and accounting rather than simply adding a backlog label.

What affects software development discovery time and cost?

Plan discovery around decisions that need evidence. Workshops, user research, requirements analysis, architecture assessment and technical validation each need an owner and an effort allowance.

Scope, integration complexity, stakeholder availability, documentation quality, migration and the depth of testing affect effort. Calendar duration also includes external waiting time, such as obtaining provider access or specialist review. A provider delay can extend the schedule without adding equivalent engineering hours.

Estimate work packages in hours or days, multiply by the applicable rates and add explicitly scoped external expenses. Keep discovery costs separate from later implementation. Use ranges where uncertainty matters and explain what would move the work towards either end.

Sequence the work around dependencies. User research and documentation review may run in parallel; payout validation may have to wait for sandbox access. Update the estimate after a blocking test or material scope change, rather than carrying old assumptions into the development commitment.

FinTech discovery readiness checklist

Use this checklist during the final review. Record the status defined in step 5 and link to evidence, rather than relying on a tick alone.

Scope and money flows

• The user problem has evidence or a clearly labelled validation plan.
• Users, markets, currencies, first-release scope and exclusions are documented.
• The operating model and responsibility boundaries have appropriate specialist review.
• Completion rules, balance effects and exception handling are defined for each journey.
• Internal balances, provider confirmation and external settlement are distinguished.

Requirements and dependencies

• Critical requirements have IDs, acceptance criteria and accountable reviewers.
• Duplicate, delayed, rejected and unknown-outcome scenarios are covered.
• Performance, recovery, access, monitoring and retention requirements have measurable acceptance conditions or explicit unresolved decisions.
• Platform-fit conclusions identify the applicable version and supporting evidence.
• Provider contracts, technical access, reports and open questions have owners.
• Fees, limits, precision and funds-availability rules have approved policies.
• Each PoC has a testable question, expected evidence and a decision owner.

Delivery decision

• The backlog covers exception handling, integrated tests and operational work.
• Estimates identify assumptions, exclusions, custom work and provider waiting time.
• Open questions have closure actions and a defined impact on delivery.
• The decision record is versioned, and material changes trigger review.

Discovery approval authorises the agreed next stage. Production launch still requires implementation, testing and the relevant operational and regulatory readiness.

Build your next FinTech product with SDK.finance

SDK.finance is a fintech software development company with 15+ years of industry experience and a team of 40+ professionals. SDK.finance helps fintech businesses, banks and payment providers assess how its platform fits their planned product. Your product brief, user journeys and money flows provide a starting point for discussing the architecture, integrations and custom work needed.

Discovery helps define the scope and responsibilities for the chosen approach.

• • Identify what can be reused. The implementation team compares your requirements with the SDK.finance Transaction Platform to determine which workflows can use existing components and which need configuration or further development. The assessment checks transaction rules, balance changes and exception handling, not just feature names.

• Define custom development and integrations. Gaps become specific tasks for backend development, customer applications, back-office workflows and external provider connections. For the wallet example, these tasks follow the requirements and operational workflows defined during discovery.
• Choose the accounting approach. Balance, posting and reconciliation requirements help establish whether the platform’s accounting model fits the product or whether the separate SDK.finance General Ledger should be evaluated for more flexible accounting schemes.
• Prepare the delivery plan. The agreed scope brings together development, integrations, testing and operational work. The estimate records its assumptions and separates work ready to begin from tasks that depend on provider access or further validation.

Where suitable, reusable platform components and 650+ APIs can reduce the functionality that needs to be built from scratch. Discovery establishes where that reuse fits your requirements and where additional development is needed.

Our SDK.finance implementation guide explains how the agreed scope progresses through platform assessment, configuration, integrations and testing to production launch. It also outlines how responsibilities can be shared between your team and a specialised development partner.

Turn discovery findings into a development plan

Discovery should leave your team able to answer three questions: what are we building, what supports the estimate and what still needs to be resolved?

Review the scope, requirements and technical findings together before committing to development. Agree which work can start and give each unresolved question an owner and a clear next action. Update the plan when product requirements or provider capabilities change.

A product brief and the main user and money flows give the SDK.finance development team a starting point for discussing the technical approach, open questions and development scope.