Every filing module had grown its own forms and its own data tables, so the same validation rule existed in several places and drifted in each of them.
Fintech · Enterprise React
Halcyon
The tax-filing interface 700+ US financial institutions use to move millions of dollars.
- Product
- Halcyon — US tax management platform, 700+ financial institutions
- Role
- Frontend engineer, VisionX Technologies
- Scope
- Enterprise React frontend, reusable form and data-table system, IRS Tax API integration
The tension
A form that accepts the wrong thing is not a UI defect. It is a filing that has to be unwound.
For institutions moving millions of dollars in filings, duplicated validation is a compliance risk rather than a maintenance cost — which made consolidation the product decision, not a refactor.
Success looked like
One home for a filing's data, validation defined once, and new screens assembled from existing primitives instead of fresh markup.
The constraint
Tax workflows are long, conditional and unforgiving, and the frontend had to be honest about latency in IRS data flows it did not control.
700+financial institutions
The install base the filing interface serves.
Millionsin tax filings
Value moving through the flows this frontend fronts.
3years on the platform
A three-year tenure on one product.
The product story
Dense, validation-heavy work, made legible.
The workspace
Filing work, front and centre.
The enterprise React interface through which 700+ institutions process tax filings, built on Ant Design primitives with the composition owned in-house.
Narrow viewports
The same contracts at every width.
Dense tabular work reflowed for narrow screens without forking the validation behaviour behind it.
The long form
Validation surfaced where the mistake is.
Server-side validation appears inline against the offending field rather than in a summary banner at the top of a long field set.
Walkthrough
The platform in motion
Recorded from the live site.
The trust test
The happy path is only half the product.
The IRS data flow stalls
The interface reports a wait it did not cause and cannot shorten, rather than rendering an empty table as though it were an answer.
A value is rejected deep in a long form
Server-side validation appears against the offending field, so a long conditional field set does not have to be re-read to find what went wrong.
One filing, two modules open
Both read the same normalised record, so neither can go on acting against a local copy the other has already moved past.
The decisions
Three moves carried the story.
Give a filing one home
Application state through Redux Toolkit with a normalised store, so a filing's data existed once and every module read from it rather than caching its own copy.
Build the primitives the domain needs
Reusable form and data-table components for long, conditional, validation-heavy field sets — which is what took duplicated UI code out of the filing modules.
Be honest about borrowed latency
The frontend integrated Node.js, MySQL and Prisma services including IRS Tax API data flows, where the interface has to communicate waits it cannot shorten.
What I would test next