Where a fintech project actually begins
A fintech application is often described by its features: an account, payment, dashboard, approval or report. Engineering starts with the meaning of each state. When has a request merely been accepted, when has it been sent to a partner and when can the operation be called complete? Which system confirms that state and what may the end user see? Without clear answers, an elegant interface may only hide uncertainty behind it.
The first stage maps the process from the initial request to a final outcome, including rejection, waiting and manual correction. It records roles, data sources, external services, reasons for state changes and points where a person decides. It also establishes constraints: market, product type, expected volume, partner availability and data sensitivity. Only then can a team decide what to develop, what to use from existing services and what the client must check through legal or contractual review.
Source of truth and change history
The same value may appear in a client portal, internal system, accounting record and external provider. Those copies are not equal. Each important field needs an authoritative source, a synchronization rule and a procedure for resolving disagreement. If a value is corrected, it should be possible to understand who changed it, when, why and how the correction reached dependent systems. This is a data-model question rather than merely a logging requirement.
Change history must help investigate a complaint or operational incident. It should not copy sensitive content into every log without thought. Events need meaningful names, a stable correlation identifier and a separation between internal technical detail and an explanation suitable for a customer. Retention and access roles should be set during design. An audit trail that no one can interpret will help neither the user nor the team responding to an incident.
Unknown outcomes and repeated requests
A network call may time out even though the other party completed the operation. The application must not automatically turn every timeout into failure or repeat an action without checking. It needs a state for an outcome under verification, an operation identifier and a way to obtain the true result. Repeated clicks, delivery of the same message and retry after an outage are normal behavior to design for, not rare optional tests.
Idempotency is more than a flag on an endpoint. Define what constitutes the same business operation, how long its identifier is retained and what happens if a later request contains changed data. Compensation or manual repair has to respect the real state on both sides of an integration. A table of states, permitted transitions and expected behavior during each outage is useful before launch. Without it, a system can pass a successful-payment test and fail at its most consequential exception.
Integrations and data contracts
A financial product may connect identity, payments, reporting, customer support and internal approvals. Each interface has its own rate of change, limits and failure modes. A contract should describe format, field meaning, versioning, timestamps, retry rules and responsibility for changes. Event flows need ordering and duplicate-handling rules; synchronous APIs need latency expectations and behavior during downtime. The design should also be understandable to the person who owns the process.
A pilot should exercise the riskiest connection against a real partner environment where possible. Example documentation may not reflect actual limits, test data or timeout behavior. Contract tests can expose interface changes before customers are affected, but they do not replace operational observation. Correlation identifiers across systems also matter: a case should be traceable without manually searching unrelated logs. The number of integrations alone is not a measure of product quality.
Permissions, security and data protection
End users, support staff, approvers and administrators need different permissions. Define them by specific actions and data rather than screen names. A sensitive change may require another approval or separation of duties. Secrets and access tokens do not belong in client code or analytics. Logs should enable diagnosis without becoming another uncontrolled copy of personal or payment information. The permission model has to survive new features and changes to staff roles.
OWASP ASVS offers an open framework for verifying technical security controls in web applications; select its scope and rigor according to risk. If a product stores, processes or transmits payment-card data, or may affect that environment, the applicable PCI DSS scope needs separate determination with qualified parties. A general page cannot declare an application compliant with any standard. Security must be evaluated in the real architecture and organization, including access management, change control and incident response.
Regulatory context and operational resilience
Obligations depend on the kind of financial entity, product and jurisdiction. In Europe, the DORA framework for digital operational resilience may be relevant to an entity in scope; the responsible legal and compliance team must assess the actual impact. Engineers need to know which records, contractual relationships, recovery tests and operating events the system must support. Designing without that input can force major changes to architecture or procedures later.
Resilience means more than an available server. The team needs to know whether requests are processed, messages are lagging, final states reconcile and recovery risks repeated operations. A database backup must be paired with a way to restore a consistent situation across connected systems. During an incident, people need to know the impact on users, who makes decisions and how to communicate. Availability measures and recovery objectives should reflect the specific service and be tested in practice.
A first verifiable delivery
The first stage need not contain the whole product, but it should carry one important path from input to verifiable result and include a meaningful exception. A request might be created, sent to an external service, receive a confirmed or unknown state and remain traceable in an internal interface. Tests of business rules, correlated events, access roles and basic monitoring belong with that path. This reveals actual integration risk more effectively than a collection of completed screens.
After the pilot, decide what to build next, what to change and what to leave to a partner service. Further estimates must distinguish known components from dependencies on partners, data or legal assessment. The client should understand the responsibility boundary: who owns the product, runs the integration, approves rules and resolves an exception. Handover includes source, contract descriptions, migration instructions, configuration without secrets and a recovery scenario. Verifiability matters more than an impressive feature list.
Questions to bring to a first conversation
Prepare an overview of user roles, the main flow, connected systems and data that cannot be lost. For each external service, indicate whether you have documentation, a test environment and someone authorized to decide about changes. Record known incidents and cases that currently require manual work. If the product is regulated, name the internal owner of legal and compliance assessment; an engineering supplier should not infer legal conclusions from an incomplete brief.
It also helps to choose the most important measure for the first stage: correct state, time to completion, fewer manual repairs or the ability to add a partner safely. Not every goal has to be achieved at once. A record of assumptions and exceptions helps determine whether to start with discovery, an integration prototype or a defined build. The conversation then moves from a vague promise of a “fintech platform” to an outcome that can later be accepted and operated.