FTX’s favored account was a setting in the code, and banks have settings too

The week

On December 12, 2022, the founder of the collapsed crypto exchange FTX was arrested in the Bahamas at the request of US authorities. An exchange, in this sense, is a platform where customers deposit money and trade digital assets.

FTX, once one of the best-known names in crypto, was already in bankruptcy. A month earlier, on November 11, a new chief executive had taken over and authorized Chapter 11 filings for more than 100 FTX entities. That week its story moved from the business pages to the courts, and from questions about markets to questions about controls.

On December 13, federal prosecutors in New York unsealed an indictment charging the founder with fraud and conspiracy. The counts covered wire fraud on customers and lenders, conspiracies to commit commodities fraud, securities fraud and money laundering, and a campaign finance conspiracy. The same day, the SEC, which regulates securities markets, and the CFTC, which regulates commodity and derivatives markets, filed civil complaints, the lawsuits regulators bring alongside or separately from criminal charges.

The SEC’s case was framed around investors. It said FTX had raised more than $1.8 billion from equity investors since 2019, about $1.1 billion of it from roughly 90 US-based investors. Those investors, it alleged, had been told FTX was a careful, well-run venue whose automated risk measures, including a proprietary “risk engine,” protected customer assets.

The SEC alleged that customer funds had been diverted to his trading firm, Alameda Research, and that Alameda received special treatment on the FTX platform. That treatment, it said, included an exemption from the automatic liquidation that applied to other customers, and an effectively unlimited line of credit.

The CFTC’s complaint went further into the mechanics. It alleged that FTX employees, at the founder’s direction, had built features into the platform’s code that favored Alameda and were never disclosed to the public. According to the CFTC, those features let Alameda trade without sufficient funds and withdraw billions of dollars in customer assets. The agency put the loss of customer deposits at more than $8 billion.

Those phrases carry most of the story. On a trading platform, automatic liquidation is a safety mechanism. If a customer borrows to trade and their losses grow too large, the system sells their holdings automatically before the losses can eat into anyone else’s money. It works like a circuit breaker in a house: it trips without anyone having to make a decision. An exemption means one account’s circuit breaker was switched off. An effectively unlimited line of credit means that account could keep borrowing with no meaningful ceiling.

The same day, the executive appointed to run FTX in bankruptcy told the House Financial Services Committee that the company had lacked basic record-keeping and financial controls. His written testimony listed what his team had found in four weeks. Senior managers had access to the systems holding customer assets, with no security controls to stop them redirecting those assets. Private keys controlling hundreds of millions of dollars in crypto were stored without effective security or encryption. Alameda could borrow customer funds without effective limits. There were no audited or reliable financial statements, no independent governance, and too few people in finance and risk roles.

He traced the collapse to an absolute concentration of control in a very small group of inexperienced people. His team had by then secured more than $1 billion of digital assets. It was, he said, starting from near zero on the record-keeping one would expect in a multi-billion-dollar business.

The week did not end there. On December 21 the founder was extradited to the United States. That night, prosecutors announced that two of his closest colleagues, Alameda’s chief executive and FTX’s co-founder and technology chief, had pleaded guilty and were cooperating. The SEC charged both the same day. It alleged that the technology chief had created the software code that allowed Alameda to divert customer funds.

For anyone running a bank, broker-dealer or wealth manager, it was easy to see all this as a crypto story, far from their own world. The more useful reading was closer to home. The special treatment, as alleged, was not a secret vault or a hidden bank account. It was a setting in the software, and modern financial firms run on settings.

The FTX collapse of December 2022 holds a lesson for regulated firms that has little to do with crypto. The alleged fraud did not depend on exotic technology. It depended on a few people being able to change how a trading platform treated one account, with nobody independent watching.

Three control questions follow for any bank, broker-dealer or wealth manager. Who can change business rules in code? Who can see money moving? And who is accountable when the same people build, run and finance the platform? The shift of financial controls from paper into software is what makes the FTX allegations relevant to everyone else, so the article starts there.

After the three questions come their consequences. The later sections cover partners, the cost of getting this wrong, the evidence a firm should be able to produce, and the board. The aim throughout is concrete. Each section names the systems, owners and records involved, because control failures of this kind are found in records, not in policies.

How financial controls moved into software

A generation ago, many of a financial firm’s most important controls lived in people and paper. A loan above a certain size needed a credit officer’s signature. A large payment needed two authorized signers. A margin call, the demand that a customer add money when their borrowed position falls in value, was made by a person who looked at the account.

The principle behind all of this is called segregation of duties: no single person should be able to start, approve and complete a sensitive transaction alone.

Over the past two decades, much of that work has moved into systems. Today a platform can check a credit limit, trigger a margin call, liquidate a position, block a suspicious payment and flag a trade for review in milliseconds, with no human involved. This is a real improvement. Software is consistent, fast and tireless, and it does not forget to apply a rule on a busy Friday.

But something subtle happened along the way. The rules themselves became data and code. A credit limit is now a number in a table. A liquidation trigger is a line of logic. An exception for a particular customer is a flag, a yes-or-no setting, attached to that customer’s account. Whoever can edit those numbers, lines and flags now holds the power that used to need several signatures. And the people who can edit them are often engineers, not credit officers.

That is not a problem in itself. It becomes one when nobody outside the engineering team is watching what changes, and why.

The anatomy of an automated control

Every automated financial control has the same four parts. There is an input, such as an account’s balance, positions and collateral. There is a rule, such as “liquidate when losses exceed collateral.” There is an action, such as selling the positions. And there is an override path, the way the business switches the rule off or changes it for a particular case.

The first three parts get most of the attention. Model validation teams test whether the rule is sensible. Engineers test whether the action fires correctly. Auditors check that inputs are complete and accurate. The override path is usually the least documented part, because it is built for convenience and used rarely.

Yet every real business needs overrides. A market maker, a firm that continuously quotes prices to keep a market liquid, may legitimately need different margin terms from a retail customer. A treasury account may need to run negative for a few hours while a wire settles. An account under legal hold may need to be excluded from automated closure. The override path exists for good reasons, and that is exactly why it is dangerous. An exception for a favored account looks, in the data, just like an exception for a legitimate one.

FTX’s Alameda was, on paper, a market maker on the exchange. That role gave a plausible cover story for different treatment. Any regulated firm with house accounts, affiliate accounts, employee accounts or institutional clients on special terms has the same ambiguity in its own systems.

Where the settings live

Business rules hide in at least four technical places, and each has different visibility:

• Parameter tables in a core system, often editable through an administrator screen. These are the most visible, and many vendors log changes to them by default.
• Feature flag services, tools that let engineers turn behavior on or off for a group of users or a single account at run time. These are fast and convenient, and their change history often lives in a tool that risk and audit teams never see.
• Configuration files and environment settings deployed with the application. Changes go through the software release process, so they are reviewed as code rather than as business decisions.
• Hard-coded logic, where an account number or a condition is written directly into the program. This is the least visible of all. Finding it means reading the source code.

A firm that wants to know which accounts are treated differently has to look in all four. Most firms that try find that the answer spans several teams, several tools and no single owner.

Why existing audit regimes miss it

Public companies, including listed bank holding companies and broker-dealer parents, already have auditors testing their IT general controls under the Sarbanes-Oxley Act. Those tests cover access to programs and data, program changes and computer operations. Larger insured banks face a similar management assessment of internal control over financial reporting under the FDIC’s Part 363 rules.

Those regimes help, but they are scoped to financial reporting. An auditor asks whether a change to a system could misstate the financial statements. A margin exception for one institutional account, or a fraud rule turned off for one merchant, may never reach that threshold until it causes a loss. The scoping logic is sound for its purpose. It simply leaves a band of business-rule changes that nobody is specifically testing.

Who can change business rules in code

Traditional segregation of duties assumed one person approved a payment and another released it. Modern platforms encode many of those approvals as rules: margin thresholds, liquidation triggers, credit limits, payment limits and account flags. Whoever can edit those rules, or create an exception for a single account, holds a power that once needed several signatures.

The SEC’s complaint described exactly that kind of exception. Regulated firms carry the same exposure in other forms:

• A configuration table in a core banking system, the central software that holds a bank’s accounts and balances, sets overdraft limits.
• A feature flag, a switch engineers use to turn a piece of functionality on or off without rewriting the software, switches off a fraud check for one merchant.
• A hard-coded exclusion, an exception written directly into the program, keeps an account out of trade surveillance, the monitoring that looks for market abuse.

Each one can be legitimate. A merchant with an unusual but genuine business may need a fraud rule adjusted. A test account may need to be excluded from surveillance. Each one is also a control that a developer can change.

Why code review is the wrong control

Code review does not close this gap on its own. In code review, one engineer checks another’s changes before they go live. Reviewers check whether a change works, not whether the business should allow it. A reviewer will catch a typo in the line that exempts an account from liquidation. They are not in a position to ask whether that account should be exempt at all.

There is also a social problem. Code review happens among peers who work together every day, often under the same manager. A reviewer who questions a change requested by a senior executive is taking a personal risk. A risk officer approving a credit exception is doing their job. The second arrangement puts the question in front of someone whose role, incentives and reporting line all point toward asking it.

The stronger control

The stronger control has four parts:

1. Inventory. Keep an inventory of business rules and account-level exceptions as data, separate from application code, so they can be listed, read and counted by people who are not programmers.
2. Independent approval. Require approval from someone outside engineering, in risk, finance or compliance, for any change to them.
3. Logging. Log every change with the approver, so there is a permanent record of who changed what, when and with whose permission.
4. Re-certification. Re-certify the full exception list on a schedule, so stale exceptions expire rather than persist.

Each part has a technical form. The inventory becomes a rules registry: a table or service where each rule and exception carries an owner, a business reason, an approver, a start date and an expiry date. The approval becomes a gate in the release pipeline, so a change to the registry cannot deploy without a recorded approval from a named group outside engineering. Many source control platforms can already enforce this by requiring sign-off from a designated group for changes to particular files.

Logging means the registry’s history is written to a store that engineers cannot alter, such as a log system owned by security or a write-once archive. Re-certification means a scheduled job produces the full exception list for the rule owner, and anything not re-approved by its date reverts automatically.

A final piece catches what the registry misses: a daily comparison of what is actually running in production against what the registry says should be running. Any difference raises an alert to the second line, the risk and compliance functions that oversee the business. That check is what finds the hard-coded exception and the flag flipped directly in a tool.

Suppose an engineer at a mid-sized broker-dealer is asked by a senior trader to raise the credit limit on one institutional account “temporarily, for a big client.” Under the old way of working, the engineer edits a value in the code, a colleague reviews it, and it goes live that afternoon. Six months later, nobody remembers the request and the limit is still raised. Under the stronger control, the request goes to the credit risk team, who approve it with an expiry date. The change appears in a monthly report of exceptions reviewed by the chief risk officer, and when the date passes, the limit reverts automatically. Same engineer, same software, very different exposure.

How the obligation differs by firm

Broker-dealers have the most specific starting point. The SEC’s market access rule, Rule 15c3-5, requires broker-dealers with market access to maintain pre-set credit and capital thresholds and to keep those controls under their direct and exclusive control. It also requires a regular review of their effectiveness and an annual certification by the chief executive. A credit-limit exception for one client is squarely the kind of setting that rule cares about. FINRA’s supervision rule, Rule 3110, adds the expectation of a supervisory system that would catch it.

Banks rarely have a rule that names configuration tables directly. Their exposure runs through safety-and-soundness expectations, credit policy, the FFIEC’s IT examination guidance and, for larger or listed institutions, the financial reporting control regimes above. In a bank, the most consequential settings tend to be overdraft and credit limits, wire and ACH limits, fraud rule thresholds and fee waivers.

Credit unions face a different shape of the same problem. Many run on a core system hosted by a vendor, so engineering access is limited, but the credit union’s own staff hold administrator rights to parameter screens. The control question becomes who inside the credit union holds those rights, and whether anyone reviews what they change.

Wealth managers and registered investment advisers carry their own version in fee schedules and billing systems. A fee waiver or a custom billing rate is an account-level exception. So is an account excluded from a model portfolio rebalance. Each should have an owner and a reason, like any other setting.

The trade-off: speed in a crisis

The strongest objection from engineering teams is speed. During a market shock or a production incident, a firm may need to change a threshold within minutes. A rule that every change waits for a risk officer can make an incident worse.

The usual answer is a break-glass path. An engineer can make an emergency change without prior approval, but the change is flagged, logged and reviewed by the rule owner within a fixed window, typically the next business day. The number of break-glass changes then becomes a metric. A firm that uses the emergency path every week has a process problem, not an emergency. A firm that never uses it may have a path nobody knows how to use.

Who can see money moving

The second question is reconciliation. Reconciliation is the routine work of comparing two sets of records that should agree, such as a firm’s own ledger and its bank statement, and investigating any difference.

The new chief executive’s testimony described a company without audited or reliable financial statements or working internal controls, whose assets could not readily be traced because records had not been kept properly. That is extreme. The smaller version is common: ledgers that reconcile in total while individual accounts or omnibus balances drift. An omnibus account pools many customers’ money in a single account at a bank or custodian, with the firm’s own records showing who owns what. The total can match while the split among customers goes wrong unnoticed.

How reconciliation works, and how it fails

A reconciliation has three moving parts. The first is the firm’s internal record, the ledger the platform maintains. The second is an external record, a statement from a bank, custodian or clearing firm. The third is the matching logic that pairs entries between the two and reports what does not match.

Each part can fail in a way that hides a problem. The internal record can be edited directly in the database, bypassing the application’s own checks. The external record can arrive through the same platform team that maintains the ledger, rather than straight from the bank. The matching logic can carry a tolerance wide enough to absorb a real difference, or a rule that auto-closes small breaks after a set time.

The best designs remove those weak points. Bank and custodian statements arrive directly from the counterparty in standard electronic formats, into a system the platform team cannot write to. Matching rules and tolerances are owned by finance or operations, with changes approved like any other business rule. Direct database edits to balance tables are blocked for everyone except a small, recorded break-glass group.

Different firms, different reconciliations

For broker-dealers, the SEC’s customer protection rule, Rule 15c3-3, and its reserve computations exist to keep customer assets separate and verifiable. The rule requires a regular computation, generally weekly, of what the firm owes customers, and a deposit into a special reserve bank account held for their exclusive benefit. It also requires the firm to keep customers’ fully paid securities in its possession or control. An account-level gap between the firm’s records and the clearing or custody records feeds straight into that computation.

Banks have general ledger and subledger reconciliation controls; the general ledger is the master set of accounts, and subledgers hold the detail behind it. Partner banks in banking-as-a-service programs, where a bank provides accounts and payment access that a fintech app presents to its own customers, depend on reconciling their records with the fintech’s. The money is usually held in a pooled account held “for the benefit of” the fintech’s customers. The bank sees one balance; the record of who owns what is kept by someone else.

Registered investment advisers with custody of client assets face a different check. Under the SEC’s custody rule, many must arrange a surprise examination by an independent public accountant to verify client assets. That examination is a periodic, outside version of the same question: can the adviser prove each client’s holdings against records it does not control.

The independence test

The practical test is independence, and it has three parts. The first is whether reconciliations are performed by people and systems outside the team that runs the platform. The second is whether breaks, the differences a reconciliation finds, are escalated with an age limit. The alternative is that they are absorbed into suspense accounts, holding accounts where unexplained amounts can stay indefinitely. The third is whether the platform team can edit the reconciliation logic or its tolerances, the size of difference the system is allowed to ignore.

Suspense accounts deserve special attention. They exist for good reasons, such as a payment that arrives without enough information to credit the right customer. Over time they also become the place where unexplained differences go to be forgotten. A suspense balance that grows slowly, with items older than a month, is often the first visible symptom of a ledger that no longer matches reality.

Useful metrics are simple. Track the number and age of open breaks, the value held in suspense accounts, and the time to produce an account-level customer balance from records the business does not control. A firm that cannot produce that balance within a day has a control gap, whatever its policies say.

Internal audit can test this directly by picking a sample of customer accounts at random and asking operations to prove each balance to bank or custodian statements, without help from the platform team. It is a plain test, and a revealing one.

Who is accountable when the same people do both

The third question is about people. In a fast-growing firm, the engineers who build a platform often also operate it, hold production access and sit close to executives making financial decisions. Production access means the ability to change the live system that customers are actually using, as opposed to a test copy.

Young fintechs, crypto firms and new digital units inside banks share that profile. Concentration of knowledge and access in a handful of people was central to how FTX operated. The bankruptcy chief executive’s testimony made that concentration the headline finding.

How concentration builds up

Concentration rarely starts as a decision. It starts with a small team where everyone does everything because there is nobody else. The first engineers set up the infrastructure, hold the administrator credentials and know where every setting lives. As the firm grows, new people join, but the founders’ access is never cut back, because cutting it would slow things down.

By the time the firm is large enough to need segregation of duties, the people who would have to give up access are the most senior and most trusted people in the building. Asking them to accept restrictions can feel like an accusation. That dynamic exists in bank innovation units and wealth management technology teams as much as in start-ups.

Regulated firms address this with three controls. Privileged access management is the set of tools and rules that control who holds the most powerful system accounts and how they use them. Production change approval is the second. The third is separation between developers, who write software, and operators, who run it. Those controls erode under delivery pressure:

• Emergency access is granted and never revoked.
• Administrative accounts are shared, so nobody can tell who did what.
• One lead engineer becomes the only person who understands a critical system, and nobody can review that person’s work.

The CIO’s question is uncomfortable but concrete: list everyone who could change how money moves without a second person seeing it, and decide whether that list is acceptable.

Controls that survive delivery pressure

Shortening it usually means just-in-time production access with automatic expiry, where an engineer receives powerful access only for a specific approved task and it lapses on its own afterward. It means session recording for privileged work, so there is a replayable record of what was done. It means a second engineer able to support each critical system. And it means making sure the head of engineering does not report solely to the executive whose results the platform produces. An engineering leader who can be overruled by the person who benefits from the numbers is in an impossible position.

Direct database access deserves its own rule. An engineer who can run a command against the production database can change a balance, a limit or a flag without going through the application at all. No application log will record it. The control is to route all such changes through an approved, recorded tool, and to alert on any direct write to tables that hold balances, limits or account flags.

The evidence an examiner or auditor will ask for is predictable. Expect requests for the list of privileged accounts and their owners, the approvals behind each grant of access, the logs of what those accounts did, and proof that departed staff lost access promptly. A firm that can pull those records from its access management tool in an afternoon is in good shape.

When the firm is too small to separate duties

A small fintech or a lean credit union technology team may not have enough people to separate every duty. That is a real constraint, and pretending otherwise produces controls that exist only on paper.

The answer is compensating controls. If the same engineer must build and deploy, someone else should review the record of what was deployed after the fact. If only one person can administer a system, their activity logs should go to a store they cannot alter, reviewed by someone outside the team. An outsourced security operations provider or internal audit can play that role. The goal is that every powerful action leaves a trace that someone independent will eventually read.

The same questions for partners

Banks and broker-dealers rely on fintechs, banking-as-a-service platforms and custodians, firms that hold assets for safekeeping, whose controls were built by small teams. Many of those teams are talented and careful. Some grew faster than their controls did.

Due diligence that reads policies tests the wrong thing. A policy describes what a firm intends. It does not show what the firm’s systems actually allow. Ask instead for:

• The change history of business rules over a recent quarter, with approvers.
• The list of accounts treated differently from standard rules, with reasons.
• The current roster of production access.

A partner with sound controls can answer in days. One that cannot answer has given its answer.

Writing it into the contract

Asking once at onboarding is not enough. The rights to ask again belong in the contract. Useful terms include audit and inspection rights that cover systems and data as well as documents, and a daily account-level ledger file delivered to the bank. They also include notice of material changes to rules that affect customer funds, and a defined handover of records if the relationship ends. The last term matters most when things go wrong, because a partner in distress is least able to produce clean records quickly.

Monitoring should then use those rights. A bank that receives a daily ledger file can reconcile it to the pooled account balance every day and treat any unexplained difference as a break with an owner and an age. A broker-dealer that introduces customers to a clearing firm can compare its own records with the clearing firm’s on the same schedule.

How partner structures differ

The shape of the dependency varies. A bank sponsoring fintech programs carries the regulatory accountability while the fintech or its middleware provider holds the customer-level records. An introducing broker-dealer relies on a clearing firm under a carrying agreement governed by FINRA Rule 4311, and the clearing firm usually holds the authoritative books. A credit union may rely on a credit union service organization, a jointly owned provider, for core processing or payments.

In each case the same three questions apply to the partner, but the power to ask them differs. A bank can make records a condition of the program. A small introducing firm has less bargaining power with a large clearing firm and may have to rely on the clearing firm’s own audit reports. Knowing which situation applies tells a firm how much it can verify directly and how much it must take on trust.

Credit losses, examiners and trust

For a regulated firm, the cost of getting this wrong is not limited to fraud. An account-level exception that nobody reviews can expose the firm to credit losses when a favored customer cannot repay. A reconciliation gap can mean customer money is not where the books say it is, which regulators treat with the utmost seriousness. A single engineer with unchecked access is a key-person risk, an operational risk and, at worst, an insider-threat risk.

Regulators increasingly examine how firms govern the code that implements their controls, as well as the written policies. Boards are expected to understand where material decisions are made. When those decisions live in a configuration table, the table belongs within the board’s line of sight.

And reputation, in financial services, is the business. Customers trust a firm with their money because they believe the rules apply to everyone equally. The most damaging allegation in the FTX complaints had nothing to do with technology: one account played by different rules.

The strongest objection

The best argument against all of this is that FTX was a fraud directed from the top, and no control framework stops a determined chief executive. If the people at the head of a firm want to move customer money, they can override any process they own. On this view, settings governance is a distraction from the things that matter, such as board independence and honest leadership.

The objection is partly right. Controls inside a firm cannot replace governance above it. Yet the FTX allegations show why the controls still matter. The favored treatment had to be built by engineers. Strong controls would have forced that work into records that people outside the inner circle could see. They would have turned a private instruction into a recorded approval, a registry entry or an alert. Fraud that requires more people to participate, and leaves more evidence behind, is harder to start and quicker to find.

The more common risk in regulated firms is also not fraud at all. It is drift: exceptions granted for good reasons that outlive them, limits raised for a client who later defaults, access granted in an outage and never removed. The same controls that make fraud harder make drift visible.

What the controls cost

None of the earlier recommendations is free, and pretending otherwise invites resistance. A rules registry takes engineering effort to build and discipline to maintain. Independent approval adds hours or days to changes that used to take minutes. Re-certification consumes the time of risk officers who already have full calendars.

The costs fall unevenly. Engineering teams carry most of the build effort, while risk and compliance carry most of the ongoing review. A sensible rollout starts with the settings that can move the most money, such as credit limits, liquidation and margin rules, payment limits and balance tables. It extends to lower-risk settings later. Firms that try to govern every flag at once tend to drown the reviewers and end up approving everything.

Three documents, produced within a day

A well-controlled firm can produce three documents within a day. The first is a list of every business rule and account exception with its owner and approver. The second is an account-level reconciliation to independent statements, with aged breaks explained. The third is a roster of everyone with production access, most of it temporary. The firm reviews all three regularly, and someone outside engineering signs off.

What each document should contain

For each entry, the exception list should show the account or rule affected and what differs from the standard. It should also show the business reason, the owner, the approver, the date granted and the expiry date. It should come from the registry, not from a spreadsheet maintained by hand. A hand-built list tells you what someone remembered, not what the system does.

The reconciliation should show, for a given date, each customer or sub-account balance in the firm’s records next to the matching external record, with every difference listed by age and value. It should state who prepared it and confirm that the external data came directly from the bank or custodian.

The access roster should list every person and service account able to change production systems that move money. For each, it should show how they got that access, whether it is standing or temporary, and when it was last reviewed. Shared accounts should appear as findings, not as entries.

The usual lapses

• Treating code review as a business control.
• Letting reconciliation be run, or tuned, by the platform team itself.
• Granting exceptions without expiry dates.
• Allowing “temporary” emergency access to become permanent.
• Assessing partners by reading their policies instead of looking at their records.

Each lapse has a simple test. Ask who approved the last five rule changes, and see whether any approver works outside engineering. Ask who can change reconciliation tolerances. Count exceptions without an expiry date. Count emergency grants older than a week. Ask which partners have sent records rather than documents. A firm that runs those five tests once a quarter will catch most of the drift before an examiner does.

Putting it in front of the board

Most boards will never read a configuration table, and they should not have to. What they can do is ask for a short, regular report that turns these three questions into numbers and trends. A useful version fits on a single page and might include:

• Exceptions. How many accounts are currently treated differently from standard credit, margin, payment or surveillance rules; how many were added or removed this quarter; and how many have passed their expiry date without review.
• Rule changes. How many changes were made to business rules in software this quarter, and what share were approved by someone outside engineering before going live.
• Reconciliation. The number and age of open breaks, the value in suspense accounts, and the result of internal audit’s latest sample test of customer balances.
• Access. How many people hold standing access to live financial systems, how many critical systems depend on a single engineer, and whether any emergency access remains unrevoked.
• Partners. Which fintech and banking-as-a-service partners have provided rule change logs, exception lists and access rosters, and which have not.

The value of such a report is less in any single number than in the conversation it starts. A rising count of expired exceptions, or a partner that has gone two quarters without providing records, is exactly the kind of slow drift that, left alone, becomes a headline.

Who owns the report

Ownership matters as much as content. If the technology function prepares and presents the report alone, the board is hearing the platform team grade its own work. A stronger arrangement has the second line assemble it from system data, with internal audit testing a sample each year. The board’s risk or audit committee is usually the right home, depending on how the firm divides those duties.

Thresholds help directors read it. The firm can set a tolerance for each line, such as no exceptions past expiry or no breaks older than a set number of days. Anything outside tolerance then needs a named owner and a date. Directors do not need to understand the systems to ask why a number is red.

Suppose a community bank that has partnered with several fintech apps receives its first such report. It shows dozens of account-level exceptions with no expiry dates, a suspense account balance nobody can fully explain, and two partners who have never shared an access roster. Nothing here is evidence of wrongdoing; all of it is evidence that nobody was looking. Within two quarters, after a few pointed board questions, the exceptions carry owners and dates, the suspense balance has been worked down with each item explained, and one partner relationship is being renegotiated. The bank has not bought any new technology. It has simply decided to see what its existing technology was doing.

Finding the settings that matter

The questions below are the ones we would put to a CIO, chief risk officer or head of operations today. They are written to be answered with records, and each maps to one of the three questions above.

• How many accounts are treated differently from our standard rules, who approved each exception, and when do they expire?
• Who outside engineering must approve a change to a business rule before it goes live?
• How many reconciliation breaks are open today, how old is the oldest, and how much sits in suspense accounts?
• Who could change how money moves without a second person seeing it, and is that list acceptable?
• For our fintech and banking-as-a-service partners, have we seen their rule change logs, exception lists and production access rosters, or only their policies?

A firm that can answer all five from records, without convening a meeting to find out, has done most of the work. A firm that cannot has found the place to start.

With hindsight

The founder was convicted on all seven counts in November 2023 and sentenced in March 2024 to 25 years in prison. The criminal case closed the question of what happened at FTX. The control question it raised for everyone else stayed open.

Three former insiders pleaded guilty and testified for the prosecution: the two whose pleas were announced in December 2022, and FTX’s former engineering director, who pleaded guilty in early 2023. All three received far lighter sentences in late 2024, ranging from time served to two years. Their cooperation mattered to the case because the favored treatment, as alleged, had been built by a handful of people who knew exactly where it lived in the code.

The CFTC’s complaint, filed the same day as the SEC’s, had described an “allow negative” flag built into the platform’s code for Alameda. It was a setting that let one account’s balance go below zero, exactly the kind of account-level exception described above. It is hard to find a cleaner illustration of how a control can be switched off without anyone noticing: not by a forged signature, but by a single setting attached to one customer.

In the bankruptcy, the new management team spent 2023 rebuilding records the old company never kept. Its first public report on control failures, in April 2023, went into much more detail on the problems its chief executive had outlined to Congress. They included concentrated access, weak protection of private keys and missing accounting records. The estate’s work became, in effect, a long and expensive reconstruction of the three documents this article describes.

US crypto policy changed course. Bank regulators issued cautious statements in early 2023, withdrew them in 2025, and Congress enacted a federal stablecoin law in July 2025. A stablecoin is a digital token designed to hold a steady value, usually one dollar. For banks, the door to digital asset activity opened wider than it had been in the months after FTX’s collapse.

The control argument did not depend on any of that. Whether a firm is wary of crypto or embracing it, its credit limits, liquidation rules and account exceptions still live in software, and someone can still change them. A bank entering digital assets under the new federal framework faces the same three questions about its own custody and ledger systems.

Bank partnership oversight moved in a parallel direction. In June 2023 the Federal Reserve, the FDIC and the OCC issued final joint guidance on managing third-party relationships, including those with fintech firms. It replaced each agency’s earlier guidance with a single framework covering due diligence, contracts and ongoing monitoring.

Failures at banking-as-a-service middleware firms, notably the 2024 bankruptcy of Synapse, showed again what happens when partner ledgers cannot be reconciled to bank records at the account level. Middleware here means the technology layer sitting between the bank and the fintech apps, keeping track of which customer owns which money. When that record and the bank’s record diverge, customers can be left unable to reach funds they believed were safe.

Regulators responded to that episode directly. In July 2024 the three federal bank agencies issued a joint statement on the risks of third-party arrangements that deliver deposit products, alongside a request for information on bank-fintech arrangements. In September 2024 the FDIC proposed a recordkeeping rule for custodial deposit accounts held for the customers of non-bank partners. The common thread was the account-level ledger: who keeps it, and whether the bank can see it.

What held up, then, was the narrow claim. Favored treatment in a financial platform is usually a setting, and settings need owners outside engineering. What changed was the context around it, from a crypto winter to a period of renewed bank interest. The question for a firm in 2026 is the same one FTX posed: who can change the line in the table.

The habit to build is looking for settings as well as signatures. In a modern financial firm, the most important controls are often a line in a table. Knowing who can change that line, and who checks, is now part of running the business.