Building Finance Controls at a Crypto Exchange From Zero

Nobody teaches this. There's no textbook for building institutional finance inside a crypto exchange. I know because I looked.

When I took on the finance infrastructure at one of the world's largest crypto exchanges, I searched for the playbook. The accounting standards hadn't caught up. The Big 4 had barely started writing guidance for crypto-native businesses. The few firms that had built real controls weren't publishing how they did it. Everything I found was either traditional finance advice that ignored on-chain complexity, or crypto-native content that ignored institutional rigor.

So we wrote the playbook ourselves. Chart of accounts to controls framework to Big 4 audit, across 100+ entities. Close cycle from 8 weeks to under 2 weeks. 200+ automated pipelines in production. What follows is the story of how that happened — the sequence, the decisions, and what I'd do again.

What I walked into

Month one was an assessment. I needed to measure the gap between where the finance function was and where it had to be for institutional credibility — Big 4 audit, regulatory reporting, board-grade financials across every entity.

The close cycle was running at 8 weeks. The team wasn't slow. The process demanded that much calendar time because every step waited on the previous one finishing, and most steps involved someone manually bridging two systems that didn't talk to each other. Reconciliation lived in spreadsheets. The controls matrix had dozens of documented gaps — and those were only the ones we could identify in the first pass. The entity count was already past 100, spread across jurisdictions with different reporting requirements, different functional currencies, and different fiscal calendars.

We knew issues existed at every layer. What we lacked was the infrastructure to see them all at once, measure their severity, and attack them in the right order.

What I had to invent

There was no template. Traditional finance transformation assumes you're starting with a functioning ERP and layering controls on top. We were starting with a multi-chain, multi-custodian, multi-jurisdiction operation where the chart of accounts hadn't been designed for the transaction types we were actually processing.

I set the sequence: chart of accounts first, close calendar second, controls matrix third. To be precise: foundational ITGC — access controls, change management, basic segregation of duties — was in place from week one. The comprehensive controls matrix had to wait because every control needs a process to govern, and the processes needed the CoA and close calendar to exist first.

The chart of accounts came first because everything downstream depends on it. If the CoA can't accommodate on-chain gas fees, staking rewards, bridge transactions, and DeFi protocol interactions as distinct line items with clear entity attribution, the ledger is broken before a single journal entry posts. We designed the CoA to handle crypto-native transaction types that no accounting textbook covered — and to scale across every entity without requiring a fresh mapping exercise at each period close.

The close calendar came second because you can't compress what you haven't mapped. We documented every step in the existing close — every dependency, every handoff, every bottleneck where calendar time burned while actual work waited. By month two, that map covered hundreds of discrete tasks across the entity portfolio. Some tasks had been running sequentially that could run in parallel. Some consumed three days of calendar time for four hours of actual work, because they sat in a queue behind a manual data pull from another team.

The controls matrix came third — and this is where the distance between crypto and traditional finance was widest. ITGC and ITAC frameworks exist for a reason. They work. But the standards were written for banks and insurers, not for companies operating across multiple blockchains with on-chain settlement, hot and cold wallet custody, and real-time DeFi interactions. We had to take the spirit of each control objective and design implementations that fit our actual operating model. Access controls for wallet infrastructure. Change management for smart contract interactions. Processing controls for automated pipeline outputs. None of this existed in a form we could adopt. We wrote it from the control objective up.

What 8 weeks to under 2 weeks actually required

The close cycle compression was a structural redesign, not a speed optimization.

The 8-week close existed because the process was sequential, manual, and entity-by-entity. A controller closes Entity A, then B, then C — each time pulling bank data manually, running reconciliation in a spreadsheet, posting adjusting entries, reviewing, moving on. Multiply that by 100+ entities and the arithmetic explains the timeline.

We attacked it in three moves over six months.

First, we parallelized. Entities that shared the same banking partners and the same chain exposure could close simultaneously. We built the data pipelines to feed entity-level reconciliation in parallel rather than in series. That alone cut significant calendar time — the work didn't get faster, but more of it happened at the same time.

Second, we automated the bridge work. The 200+ pipelines we deployed weren't a single project. They accumulated as we solved each bottleneck. A pipeline for bank-to-book reconciliation. A pipeline for on-chain transaction ingestion per chain. A pipeline for variance detection. Each one replaced a manual step that had consumed analyst hours every period. By month three, the controller's job had shifted from building the close to reviewing it — scanning exceptions rather than producing the baseline numbers.

Third, we baked controls into the workflow rather than bolting them on afterward. Every automated pipeline had logging, provenance tracking, and exception routing built in from the start. The controls framework grew alongside the automation, not as a separate workstream. Month one, the controls matrix had dozens of documented gaps. By month six, we had hundreds of controls mapped — each one tied to a specific process, a specific pipeline, and a specific audit objective. The close cycle compression was a byproduct. We were building institutional infrastructure, and the close got shorter because the manual work that had stretched it to 8 weeks was disappearing.

When the auditor ran the first sample

The moment that validated the entire build came during the first Big 4 audit cycle after the infrastructure was in place.

The audit team selected a sample of transactions for detailed testing. Each one needed full provenance — from the originating event through every transformation to the final journal entry, with every control point documented.

Here is what one of those looked like. An ETH transfer moved from a hot wallet to a custodian address mid-afternoon on a Tuesday. The custody platform logged receipt within minutes — automatically reconciled against the on-chain hash. On the fiat rail running in parallel, the corresponding wire to the operating bank cleared a few days later, matched back to the original on-chain event by reference key. The ERP joined both rails and posted the journal entry the same day the wire settled. From the original on-chain transaction hash to that journal entry: four clicks in the provenance chain. Every transformation logged with timestamp, source system, rule applied, and the control that governed it.

We produced full provenance for every transaction in the sample within an hour. The auditors had budgeted a week for evidence gathering. That phase effectively collapsed to zero.

That was the moment I knew the infrastructure worked. The audit tests everything at once — data completeness, processing accuracy, control effectiveness, documentation sufficiency. If the auditor can pull any transaction at random and trace it end-to-end without asking your team to reconstruct a workbook overnight, the foundation is locked. If they can't, no amount of dashboard polish or pipeline count will save you.

Building something that runs without you

The hardest part wasn't building the infrastructure. It was building it so it would survive my departure.

A finance function built around one person's knowledge is a liability, regardless of how good the systems underneath it are. If the close depends on someone knowing which pipeline handles which exception, or which entity has the special intercompany treatment, or where the manual override documentation lives — that knowledge walks out the door when the person does.

We solved this in three layers.

The agents themselves. 200+ automated pipelines don't need institutional memory. They run on schedule, handle exceptions by classification rules, and log everything. The reconciliation runs at 3am whether anyone is watching. The variance detection fires before the controller logs in. That automation encodes the operational knowledge into something that doesn't depend on any single person's presence.

Documentation written as we built, not after. Every pipeline, every control, every exception-handling rule — documented with the rationale, not just the procedure. When a new team member asks why staking rewards route through a different classification logic than transfer transactions, the documentation explains the accounting treatment and the control objective behind it. Retrospective documentation always has gaps. Writing it in real time was a discipline we enforced from month one.

The team. I built a finance infrastructure team from zero. Hired for judgment, not just execution. The team needed to understand the infrastructure well enough to modify it, extend it, and handle the edge cases that no automation anticipates. Agents handle the volume. Humans handle the decisions that require professional judgment. That division is also the structure that makes zero-day close achievable over time — because continuous improvement requires people who understand the system deeply enough to evolve it.

The function we built had to hold without the person who built it. The agents keep running. The controls keep logging. The documentation keeps answering questions. Institutional infrastructure means it doesn't depend on any one person. That's the standard.

Frequently asked questions

How do you build finance infrastructure for a crypto exchange?

Start with the chart of accounts and close calendar. Then build controls. Then automate. The sequence matters — automating a broken process just produces broken results faster.

What controls do crypto companies need to pass audit?

At minimum: ITGC (change management, access controls, backup/recovery, operations) and ITAC (input validation, processing controls, output controls) mapped to every financial system and data pipeline.

How can crypto firms reduce their month-end close?

Automate reconciliation and intercompany eliminations first — they consume the most controller time. Then standardize journal entry templates. Then layer AI agents for variance analysis and exception routing. Close compression is a byproduct of better infrastructure.

What's the difference between fast close and zero-day close?

Fast close is a milestone (cutting from weeks to days). Zero-day close is the destination — books that are always current, always reconciled, never "closed" because they were never behind.

Do crypto exchanges need SOX-equivalent controls?

If you're heading toward IPO, institutional fundraising, or heavy regulatory scrutiny — yes. The firms that build controls proactively control the audit timeline. The ones that bolt them on under pressure don't.

---

If you're building finance infrastructure from scratch — or rebuilding what grew faster than the controls around it — the gap between where you are and institutional grade is knowable. We find it in 2-4 weeks. Fixed scope. Fixed fee. Board-ready report.