Coinbase puts FDEs inside its own Finance and Compliance teams

On 13 October 2026, Coinbase posted an opening for a Forward Deployed Engineer for Finance, based in the Office of the CTO. Nine days later a second posting appeared, this time for an FDE for Compliance. Neither role’s customers have signed a contract with Coinbase. They are colleagues in the same company.

If you work as an FDE or want to become one, this detail deserves a close look. The usual picture of an FDE is an engineer sent to work on site with an external customer.

Coinbase’s two postings use exactly that model but turn it inward, aiming it at two functions where every automated result has to stand up in front of auditors or regulators.

The lesson lies in the success criterion the two job descriptions set. An agent that runs is not enough. Every result it produces must be explainable to someone with the power to reject it. In these roles, what the FDE actually delivers to the business is a chain of evidence; automation is only the means of producing it.

Why does Coinbase need this role now?

In May 2026, Coinbase cut about 14% of its staff. CEO Brian Armstrong gave two reasons: AI, and a declining crypto market that meant the company had to adjust its cost structure immediately. In the same memo, he wrote that non-technical teams were now shipping code to production themselves.

Armstrong also described the operating model he wants: AI at the centre, with humans around the edges to align it. Work is being reorganised into small pods run in an AI-native way, some of them a single person.

Read against that backdrop, the two postings follow a clear logic. If non-technical teams can already ship code to production, as Armstrong describes, what is missing is probably not people who write code but people who know how to make automation hold up when the auditors arrive.

“Humans around the edges” sounds simple, but making it real in a system takes someone to design it, and the two job descriptions give that job to the FDE.

Two postings, one shared criterion

Read separately, the job descriptions look like two quite different roles. Read side by side, they share the same structure; only the examiner differs.

Aspect	FDE, Finance	FDE, Compliance
Posted	13 Oct 2026	22 Oct 2026
Internal customer	FP&A & Treasury, responsible for more than 60 subsidiaries worldwide	The Compliance function, joining as founding engineer
Scope	Financial planning, treasury, compliance workflows	Transaction monitoring, sanctions screening, audit trail
Key design guidance	SOX, segregation of duties and human-in-the-loop as top priorities	Build on Coinbase’s existing AI platform by default
Decision rights	Owns the automation roadmap and build-vs-buy strategy	Builds and deploys AI tools for the organisation
Output must be defensible before	Auditors	Regulators

The last row matters most. The two job descriptions use almost the same sentence: every automated output must be traceable, reviewable and defensible. The sentence stays the same, with “auditors” swapped for “regulators”. Coinbase treats this as one standard applied to two functions.

Where must a number trace back to?

Take a concrete case. FP&A & Treasury is responsible for more than 60 subsidiaries. Suppose you build an agent that writes the commentary on variance between actuals and plan for each subsidiary every month. That is at least 720 pieces of commentary a year, any of which an auditor might pick out and question.

The three requirements in the job description apply to each one. Traceable means every number points back to its source data rows, along with the prompt and model versions that produced it.

Reviewable means someone can see the agent’s draft, the edits a person made, and the name of whoever signed off. Defensible means that when someone asks “why”, the answer already sits in the system rather than in somebody’s memory.

Segregation of duties makes the problem harder. The agent that drafts a journal entry should not also be the thing that posts it. The engineer who writes the pipeline should not be the one who approves its output. These boundaries have to be built into access design from the start, because adding them once the demo is running is very hard.

So in your first week with a customer like this, do not rush to ask which process takes the most time. Ask the controller what the auditors asked about last year. That answer is the real spec for the system you are about to build.

Compliance: when the examiner is a regulator

In Compliance the approach is the same but the stakes are higher. Picture a sanctions screening alert that the agent proposes to close as a false positive. If a regulator later asks about it, the system must show what data and which rules the agent relied on, and who pressed the button to close it.

The Compliance job description also contains a very practical instruction: use Coinbase’s existing AI platform as the default foundation. For a founding engineer, this is a reminder of discipline. Your job is to put AI in the right places in transaction monitoring and the audit trail, not to build a new stack because it is more interesting.

“Founding engineer” also signals how broad the scope is. As the first engineer in a business function, you do your own discovery, decide what to automate first, and build trust with people who have long been used to doing the work by hand. There is no account manager between you and the users.

Who decides whether to build or buy?

The Finance job description gives the FDE responsibility for setting build-vs-buy strategy for finance tools, and for owning the automation roadmap. That is a product role. An internal FDE has to know when to buy off-the-shelf software instead of writing it, and has to answer for that choice.

The requirements also show what Coinbase values. The job description asks for 5 or more years of experience shipping systems to production, but does not require a CPA. Finance knowledge can be learned on the job. The judgement of someone who has run real systems cannot be picked up so quickly.

Compared with an FDE serving external customers, the internal role has its own difficulty: there is no contract to fall back on. If the automation gets it wrong, the person who has to face the auditors is a colleague on the same floor, and they will remember.

Which skills are in demand?

If you want to aim for roles like these, at Coinbase or any company with a heavily constrained finance function, read job descriptions for three keywords.

“Build-vs-buy” tells you that you will be making product decisions. “Human-in-the-loop” tells you that you must design stopping points for people. “Traceable” tells you that what you hand over includes the audit trail.

In a portfolio, one agent with a complete audit log is more convincing than ten polished demos. Each output should record its inputs, versions, reviewer and time of approval. When writing your CV, describe results in a way an auditor could read: which process was automated, at which step humans keep control, and who signed off.

In interviews, be ready to explain segregation of duties using an example from your own system. The interviewer may well not care which model you used. They will ask: if this output is wrong, who catches it, and how?

When even non-technical teams can ship code to production, the scarce skill becomes making automation survive the hardest questions from auditors and regulators. At Coinbase, at least, that skill has now become two dedicated FDE roles, placed right in the Office of the CTO.