Over the last few weeks I have worked on changes that looked small in isolation: a new instrument, a revised transaction response, a member-only feature switch, a support conversation, a mobile release and a report filter.
The difficult part is that the same business capability has to remain correct everywhere it appears. It may start in a database and then travel through an API, an admin portal, a customer web portal, a mobile app, an email, a report and an operational alert. Each surface has a different job, but they all need to agree about what happened.
That is why financial software features do not really ship once. They ship per surface, per audience and per operating responsibility.
The screen is usually the smallest part of the change
It is tempting to estimate a feature from the visible work: a new field on the page, a button in the portal, a mobile navigation item or a switch in the admin area.
But a visible control is only one contract in a larger chain.
The data contract defines what the value means. The permission contract defines who can see or change it. The API, presentation, operational and release contracts then have to carry that meaning through to the people who use and support it.
If one of those contracts is missing, the work does not disappear. It becomes manual checking, support questions, inconsistent reports or an incident later.
A new instrument is not a new dropdown item
Market infrastructure makes this particularly obvious.
Adding support for an instrument or provider is not finished when the symbol appears in an admin list. The system still needs its identity, pricing source, subscription, permissions, economics and the way orders and positions are represented afterwards.
The timestamps matter as well. A quote is not simply fresh or stale because a message arrived. The bid and ask may have different timestamps, and a downstream decision needs to know whether the usable part was current.
Operations also needs to see whether the session is connected, the symbol is entitled, market data is flowing, orders are being rejected or an account needs reconciliation after a fill.
Standards such as FIX provide a common language, but the business still has to map it to instruments, accounts, permissions, reports and controls.
A new instrument is not a dropdown item. It is a new agreement between the source, the platform, the account, the client and the operations team.
A transaction can be complete in one system and incomplete in another
Money movement creates the same problem in a different form.
A deposit or withdrawal may have an external reference, request record, approval state, ledger entry, client-facing status, admin view and notification. Those are related, but not interchangeable.
An external confirmation does not automatically mean that the internal balance is ready to change. An approved request does not necessarily mean that the client has been notified. A transaction shown in an admin table does not prove that the mobile client can interpret the response.
The safer approach is to define the source of truth and evidence for each stage.
For every money movement, I want to know:
- Which record represents the original intent, and which evidence confirms the external action?
- Which rule allows the internal state to change?
- Which surfaces can show the current state, including waiting and failed states?
- How can an operator trace the client-visible result back to the original event?
This is about stopping two systems from quietly making different assumptions about the same money.
Feature flags are not just switches
Feature flags are useful when a capability needs a controlled rollout. They separate deployment from exposure and let operations test or disable a new path.
They also introduce another surface that needs to be designed properly.
The admin portal may control a global flag while another value controls individual access. The web portal may read one set of values while the mobile app reads another. The API may enforce a permission that the UI has not displayed, or a cached value may leave one client showing a feature after it has been disabled elsewhere.
The important questions are:
- Who is the feature for, and which system owns the decision?
- Which clients consume it, and what happens when one is behind the API version?
- Is the disabled state safe, understandable and reversible?
- Can support see why a user has or has not got access?
The flag is part of the product's permission and release model. It is not a cosmetic control in an admin screen.
Web and mobile are not interchangeable clients
The goal should not be to make every web and mobile screen identical. They have different constraints. What cannot differ accidentally is the underlying meaning.
If a transaction has an arrival date, both clients need to understand it in the same way. If an account can be shared read-only, the permission must mean the same thing on both platforms. A support ticket should not have a different state model depending on the device.
An API response that works for the web client but breaks the mobile client is not a minor compatibility issue. It creates two interpretations of the same business event.
Mobile release tooling adds another layer. An uploaded build is not necessarily processed, available to testers or installed successfully. Installation is stronger evidence than an upload receipt.
The surface map I use
Before calling a feature complete, I write down a small surface map.
1. Name the business capability
Use a plain description. "Show the expected withdrawal date" is more useful than "add a field to the withdrawals table".
2. List every surface
List the API, admin tools, web, mobile, email, reports, notifications, monitoring and support. Not every feature needs every surface, but the decision should be explicit.
3. Define the source of truth
State which record owns the meaning, which records are projections, and how updates or corrections travel.
4. Define identity and permission
Document who can see or change it, including the behaviour for an unentitled user.
5. Define the failure and fallback states
Decide what the user sees when data is late, a provider is unavailable, a release is behind or a downstream service rejects the request.
6. Define evidence of completion
Choose evidence that proves the business outcome: a contract test, reconciled record, audit entry, browser check, mobile installation or expected alert.
This approach is close to the distinction between uptime and readiness in Platform Uptime Is Not the Same as Operational Readiness. It also extends the idea in Financial Operations Need Operating Loops, Not More Dashboards: a dashboard or screen can show a state, but an operating loop explains what the business can do with it.
What good looks like
A feature is in a good place when the surfaces do not have to be identical, but they do agree.
They agree about what the capability means, who can use it and which states matter. They fail clearly, leave evidence for support and operations, and can be released, tested and rolled back without relying on memory.
The FCA's recent work on consumer understanding makes a similar point from the customer side. Good communication is an end-to-end process involving design, testing, monitoring and governance. A change that is confusing on one channel is not fully successful just because the API returned the right value.
This is also why I am wary of the phrase "feature complete" when it only means that one happy path works in one client.
Financial software is a multi-surface product even when the business thinks of it as one platform. The real delivery work is making sure that data, permissions, behaviour, communication, release and operational evidence stay aligned.
The visible screen is only the last part of that agreement.
This is operational commentary only. It is not investment advice, regulatory advice, or a recommendation about any specific financial service or technology provider.
