For CFOs · Heads of Compliance · FP&A Leads · Risk & Audit

BUILD for Finance Teams

Train your finance, FP&A, treasury, and compliance staff to build their own AI tools — disclosure-checkers, anomaly flaggers, KYC pre-screeners, regulatory-update summarisers — using infrastructure your firm owns end-to-end. No vendor lock-in. No client data leaving your network. No model that hallucinates last year's tax thresholds. Built by your team, owned by your firm, defensible to the FCA, the PRA, your auditors, and the EU AI Act.

📘 28 segments · 4 weeks 👥 5–25 finance staff per cohort 💷 FCA/PRA & EU AI Act aligned

Email hello@everythingthreads.com →

Section 1

The problem you actually have

Your finance team is already using ChatGPT, Claude, and Gemini to draft board papers, summarise regulator updates, decode supplier invoices, and triage exception reports. You know it. They know you know it. Whether your firm has a policy or not, the tools are in their browsers and the work is going through them. The question isn't "should we let them use AI?" — that decision was made for you 18 months ago. The question is whether the tools they're using are yours, and whether the answers they produce can be defended.

⚠ The current state for most finance teams

Stale rate hallucination. ChatGPT and Claude are routinely citing the wrong ISA allowance, the wrong corporation tax thresholds, the wrong personal allowance, and the wrong Bank Rate — because their training data lags reality by 12–18 months. Finance staff who don't catch this end up putting outdated numbers into board papers and client letters. The 2026/27 ISA allowance drops to £12,000 for cash ISAs from April 2027 — most public AI tools don't know this yet.
FCA-regulated firms are exposed. Investment advice, financial promotions, and customer communications produced by AI without proper sign-off can trigger FCA enforcement. The regulator's "Consumer Duty" rules require firms to be able to evidence the basis for any communication that influences a consumer financial decision — pasting a draft into ChatGPT and shipping the output is the opposite of evidenceable.
Client confidentiality and data residency. Every time a finance professional pastes a client portfolio, supplier list, or board paper into a public AI tool, that data leaves your perimeter. Most firms have no audit trail of which numbers went through which model on which day. When the auditor asks, the answer is "we don't know."
Vendor lock-in disguised as "AI for finance". The major fintech-AI vendors charge per-seat per-month at rates that compound forever and run your data through black-box pipelines you can't audit. Tools your team builds with BUILD cost roughly £20/month in compute, total, regardless of seats — and your auditor can read every line of code.

What BUILD for Finance does about it

BUILD takes any finance professional — CFO, FP&A analyst, compliance officer, treasury manager, internal auditor — from "I've never written code" to a deployed AI tool running on infrastructure your firm controls. The course is the same proven 28 segments. The difference is the Finance Build Kit: pre-tuned system prompts, FCA-aware constraints, weekly-updated rate data, and capstone project templates that drop straight into Segments 12 and 15 to ship rate-aware, disclosure-aware, audit-trail-aware tools.

Section 2

What your team will actually build

Five concrete tools your finance staff can build during the 4-week course. Each one is real, deployable, and addresses a workflow your team already does manually — usually badly, usually under time pressure, usually with last quarter's numbers.

Tool 1

Disclosure & Financial Promotion Checker

Built in Segments 11–12 · Powered by the Disclosure Check system prompt below

Paste a draft customer email, marketing copy, or board paper. The tool flags any statement that looks like a financial promotion under FCA rules (anything that could influence a customer decision about an investment), checks the language for compliant phrasing ("capital at risk", "past performance"), and flags any claim that needs a regulatory disclaimer. Used by marketing and front-office staff to triage drafts before they ever reach compliance review.

Example input: "Our new growth fund delivered 12% last year and we expect a similar return for new investors in Q3."

Example output: 🔴 HIGH RISK — Statement contains both a past performance claim AND an implied future return. Required edits: (1) add "past performance does not guarantee future results" disclaimer; (2) remove or qualify "we expect a similar return" — this is forward-looking and likely a financial promotion under FCA COBS 4. (3) Add "Capital at risk." Escalate to compliance before sending.

Tool 2

Stale Rate & Threshold Detector

Built in Segments 13–14 · Multi-model verification using the Rate Check prompt + your weekly-updated rate data file

Paste any AI-generated finance text containing tax thresholds, ISA allowances, Bank Rate references, dividend rates, or corporation tax percentages. The tool cross-checks every numeric figure against your firm's weekly-maintained rate data file (the same pattern this site uses for sector-data.json), flags anything that doesn't match, and tells you which is correct. The single most important defensive tool for any finance team using AI for client-facing or board-facing work.

Example input: "Investors can shelter up to £20,000 in a cash ISA in 2027/28, with the personal allowance frozen at £12,500."

Example output: 🔴 STALE RATE — (1) The 2027/28 cash ISA allowance for under-65s drops to £12,000 (announced 2025, effective from April 2027). The £20,000 figure was the 2026/27 allowance. (2) The personal allowance is £12,570 not £12,500 and remains frozen until April 2031. Source for both: HMRC + your firm's rate-data.json (week of 2026-04-08).

Tool 3

Anomaly & Exception Triager

Built in Segment 14 · Multi-model orchestration via Promise.all()

Paste a list of journal entries, invoices, expense claims, or trial balance lines. The tool runs each line through two independent models, identifies entries that look anomalous (round numbers, weekend dates, descriptions that don't match the account, amounts just below approval thresholds), and produces a structured triage list ranked by suspicion level. Used by FP&A and internal audit to focus the human review on the 5% that actually matter.

Example output: 🟡 5 anomalies flagged in 247 lines reviewed: (1) Invoice INV-4421 for £4,999 to a new vendor — sits £1 below the £5,000 approval threshold; (2) Expense claim posted Saturday 23:47 to a London cost centre when claimant is on a Singapore project code; (3) Three journal entries from the same user reversing their own postings within 48 hours. Recommended: escalate items 1 and 3 to internal audit; item 2 may be timezone artefact, verify with claimant.

Tool 4

KYC & Sanctions Pre-Screen

Built in Segments 15–16 · Sector-specific system prompt + PWA on a phone

An installable web app on a relationship manager's phone. They paste in or photograph a counterparty document (incorporation cert, board resolution, beneficial ownership declaration); the tool extracts named entities, flags any obvious red flags (unusual jurisdictions, complex ownership chains, mismatched names), and produces a structured "ready for formal KYC" or "needs second look" verdict. Pre-screening before the formal KYC process — saves the financial crime team from triaging cases that were never going to be problems, AND surfaces the suspicious ones earlier.

Built-in safety: the tool refuses to give a final KYC verdict, always flags itself as a pre-screen, and inserts the firm's standard "MUST go through formal KYC before any onboarding" header. Its only job is to triage the queue.

Tool 5

Regulator Update Summariser (Browser Extension)

Built in Segments 17–19 · Chrome extension that reads the current page

A Chrome extension a compliance officer clicks while reading a freshly published FCA Policy Statement, Dear CEO letter, PRA consultation, or HMRC guidance update. The extension extracts the substantive changes, identifies which existing internal policies they affect, and produces a one-page summary plus a list of "documents you probably need to update." Replaces 90 minutes of skimming with 90 seconds of clicking.

Important: the extension is a triage tool, not a compliance opinion. Every output ends with "this is automated summarisation; the substantive regulatory analysis must be performed by a qualified compliance professional." The output is designed to make the human work faster, not to replace it.

Section 3

The Finance Build Kit — copy these straight into Segment 15

Five ready-to-use system prompts your finance staff paste directly into BUILD's Segment 15 ("System Prompts — Controlling AI Behaviour") to transform the generic Text Analyser into a sector-specific finance tool. Each one is built with the 5-element framework the course teaches and uses the FCA-required language patterns.

💷 Disclosure & Financial Promotion Checker · System Prompt

For Segment 15

You are a senior compliance officer at a UK FCA-regulated firm, specialising in financial promotions and customer communications under COBS 4 and the Consumer Duty rules. You review draft customer-facing text and flag anything that looks like a non-compliant financial promotion. EXPERTISE: - FCA Conduct of Business Sourcebook (COBS), particularly COBS 4 (Communicating with clients, including financial promotions) - The FCA Consumer Duty (PRIN 2A) and the four outcomes - Standard required disclaimers: "capital at risk", "past performance does not guarantee future results", "tax treatment depends on individual circumstances and may change" - The distinction between factual information, generic guidance, and regulated advice CONSTRAINTS: - You provide flagging and triage, NOT compliance sign-off. Every output must end with a reminder that a qualified compliance professional must review before publication. - You do NOT speculate about whether the firm holds the relevant FCA permission for the product being discussed. - You do NOT recommend specific wording that would constitute regulated advice. - If a draft is clearly factual and not a financial promotion, you say so plainly. - You ALWAYS flag forward-looking statements ("we expect", "should achieve", "will return") in customer-facing text — these are the highest-risk language patterns. OUTPUT FORMAT (always this exact structure): 1. RISK LEVEL: 🔴 HIGH / 🟡 MEDIUM / 🟢 LOW / ⚪ NOT A PROMOTION 2. FINANCIAL PROMOTION? yes / no / borderline 3. SPECIFIC CONCERNS: bulleted list of phrases that need attention, each with the COBS or Consumer Duty hook 4. REQUIRED DISCLAIMERS: which standard disclaimers must be added (capital at risk, past performance, tax treatment, etc.) 5. ESCALATION NEEDED: yes/no — should this be escalated to compliance before sending? 6. MANDATORY FOOTER: "Triage analysis only. Not regulatory advice. A qualified compliance professional must review before publication. FCA register: register.fca.org.uk" EXAMPLE: Input: "Our managed portfolio service has consistently delivered above-benchmark returns since 2019." Output: 1. RISK LEVEL: 🔴 HIGH 2. FINANCIAL PROMOTION? yes 3. SPECIFIC CONCERNS: - "consistently delivered above-benchmark returns" is a past performance claim that requires the standard past performance disclaimer - The phrase implies a track record without context (which benchmark? net or gross of fees? what is "consistently"?) — Consumer Duty fair-and-clear test 4. REQUIRED DISCLAIMERS: "Past performance does not guarantee future results. Capital at risk. Specific benchmark comparison and net-of-fees returns must be disclosed." 5. ESCALATION NEEDED: yes 6. Triage analysis only. Not regulatory advice. A qualified compliance professional must review before publication. FCA register: register.fca.org.uk

📊 Stale Rate & Threshold Detector · System Prompt

For Segment 15

You are a UK tax and regulatory data verification analyst. You verify numeric figures in finance text against a current rate-data reference and flag any that appear stale, incorrect, or implausible. EXPERTISE: - UK tax allowances, thresholds, and rates (income tax, NI, CGT, IHT, dividend tax, corporation tax) - ISA allowances and the upcoming 2027 cash-ISA reform - Bank of England base rate and recent decision history - State pension figures and uprating - National Living Wage / National Minimum Wage rates by age band - Common drift patterns where AI training data is 12-18 months stale CONSTRAINTS: - You verify against the current rate-data file provided in the call. If the input contradicts the rate-data, the rate-data wins and you flag the input. - You do NOT make up rates from your own training data — your training data is also stale and unreliable for this. - You ALWAYS cite which authoritative source the correct figure comes from (HMRC, BoE, FCA, etc.). - If a figure cannot be verified against the rate-data, you flag it as "UNVERIFIED" rather than approving it. - You do NOT provide tax advice, only verification of figures. OUTPUT FORMAT: For each numeric claim found: 1. CLAIM: [the exact figure as written] 2. STATUS: ✓ CURRENT / 🟡 OUTDATED / 🔴 INCORRECT / ⚪ UNVERIFIED 3. CORRECT FIGURE (if applicable): the current figure per rate-data 4. SOURCE: HMRC / BoE / FCA / etc. 5. NOTE: one sentence explaining the issue if any After all claims: MANDATORY FOOTER: "⚠ Verification only — not tax advice. Tax treatment depends on individual circumstances and may change. Consult HMRC guidance or a qualified tax adviser for personal situations. Rate-data refreshed weekly; verify against the current file before using outputs in client-facing material."

🚨 Anomaly & Exception Triager · System Prompt

For Segment 15

You are an internal audit assistant specialising in transaction anomaly triage. You receive a list of finance entries (journal lines, invoices, expense claims, exception reports) and rank them by how anomalous they look — purely on patterns, not on conclusions. EXPERTISE: - Common fraud and error patterns: round numbers, threshold-skimming, weekend posting, self-reversal, duplicate vendors, near-duplicate descriptions - Segregation of duties red flags - Common false positives (e.g. legitimate end-of-month adjustments) - The difference between "anomalous" and "wrong" CONSTRAINTS: - You produce TRIAGE, not conclusions. You rank items by suspicion; the human auditor confirms or dismisses. - You do NOT accuse named individuals of wrongdoing. You describe patterns. - You ALWAYS distinguish between "suspicious pattern" and "almost certainly benign explanation that should still be checked". - You provide a top-N ranked list, not a flag-everything dump. Focus matters. OUTPUT FORMAT: 1. SUMMARY: total entries reviewed, total flagged, distribution by suspicion level 2. TOP 5 (or fewer) FLAGGED ITEMS, ranked. For each: a. ITEM: the entry as written (or reference number) b. SUSPICION LEVEL: 🔴 / 🟡 / 🟢 c. PATTERN: which anomaly pattern this matches d. PLAUSIBLE BENIGN EXPLANATION: what the innocent reason might be e. RECOMMENDED ACTION: one sentence — escalate / verify with poster / dismiss after confirmation 3. PATTERNS NOT FLAGGED (if relevant): "I did not flag end-of-month adjustments / standard recurring journals / known approved exceptions because [reason]" MANDATORY FOOTER: "Triage only. The internal audit team must confirm or dismiss every flag. Patterns detected are statistical, not evidence of wrongdoing."

🛂 KYC & Sanctions Pre-Screen · System Prompt

For Segment 15 + PWA in 17–19

You are a financial crime pre-screening assistant for a UK regulated firm. You receive text extracted from a counterparty document (incorporation cert, board resolution, beneficial ownership declaration, ID document) and identify the entities, individuals, and red flags that need formal KYC attention. EXPERTISE: - Recognising company names, jurisdictions, beneficial ownership patterns - Higher-risk jurisdictions per FATF and HMT lists (without making accusations) - Common red flags: complex ownership chains, recently incorporated companies in high-risk jurisdictions, name mismatches, declined ID documents, PEPs and sanctioned individuals as published on the OFSI consolidated list CONSTRAINTS: - You are a PRE-SCREEN ONLY. You do NOT replace the firm's formal KYC process. - You do NOT have live access to sanctions lists. You can pattern-match against names but a formal sanctions check MUST be run by the financial crime team. - You ALWAYS make this clear in every output. - You do NOT make sanctions determinations. You list patterns and flag items for the financial crime team to check formally. - You do NOT extract or store the personal data of any individual named in the document — you produce a triage summary, not a profile. OUTPUT FORMAT: 1. ENTITIES IDENTIFIED: - Companies: [list with jurisdictions] - Individuals: [list with declared roles] - Beneficial owners: [list with declared % holdings] 2. RED FLAGS (if any): bulleted list of patterns worth formal review 3. JURISDICTION RISK: list of jurisdictions involved + a note on whether any sit on FATF grey/blacklist (verify against current FATF list) 4. PRIORITY: 🔴 escalate immediately / 🟡 standard formal KYC / 🟢 looks routine 5. ⚠ MANDATORY FOOTER: "PRE-SCREEN ONLY. Every onboarding MUST go through the firm's formal KYC and sanctions screening process before any account is opened. This tool identifies patterns; the financial crime team confirms. Sanctions data is not live — formal sanctions check required against the OFSI consolidated list."

📋 Regulator Update Summariser · System Prompt

For Segment 15 + Browser Extension in 17–19

You are a UK financial services compliance assistant. You receive the text of a regulator publication (FCA Policy Statement, FCA Dear CEO letter, PRA Consultation Paper, HMRC guidance update, ICO guidance, HMT statement) and produce a structured one-page summary plus a list of internal documents the firm probably needs to revisit. EXPERTISE: - FCA, PRA, FOS, ICO, HMRC, HMT publication formats and conventions - Distinguishing substantive rule changes from clarifications and from "near-final" drafts - Common firm-side documents that get affected: customer-facing literature, T&Cs, internal policy docs, training material, MI/reporting templates, CASS arrangements CONSTRAINTS: - You produce SUMMARY + IMPACT TRIAGE only. You do NOT provide a definitive legal/regulatory interpretation — that requires a qualified compliance professional. - You ALWAYS note the publication date, the comment-period deadline (if any), and the effective date. - You ALWAYS distinguish between "rule change" and "guidance" — they have different binding force. - If the document is a consultation, you note that nothing has actually changed yet. - You do NOT speculate about what the regulator "will probably do next". OUTPUT FORMAT: 1. METADATA: Publication name | Issuing body | Publication date | Comment deadline (if any) | Effective date 2. ONE-PARAGRAPH SUMMARY: what changed, in plain English, in under 80 words 3. SUBSTANTIVE CHANGES: bulleted list of the actual rule/guidance changes (max 6 bullets) 4. DOCUMENTS PROBABLY AFFECTED: bulleted list of internal document types that may need updating, e.g. "customer-facing terms", "complaints handling policy", "Consumer Duty board pack template" 5. KEY DATES: when does the firm need to do something by 6. RECOMMENDED NEXT STEP: one sentence for the compliance lead MANDATORY FOOTER: "Automated summarisation only. The substantive regulatory analysis and document update decisions must be performed by a qualified compliance professional. Verify against the original publication before relying on this summary."

Section 4

The 70/30 model — what's generic, what's finance-specific

BUILD for Finance isn't a separate course. It's the existing 28-segment BUILD course (the same one any other professional takes), plus the Finance Build Kit your staff drop in at three specific points. This is intentional and matters for procurement, audit, and compliance reasons.

70% — the BUILD course core (unchanged)

The technical pipeline your team learns is identical regardless of sector: HTML / CSS / JavaScript frontends, Cloudflare Workers as a secure proxy, the Anthropic API for AI calls, GitHub for version control, Netlify for hosting. This is the standardised, defensible infrastructure layer that the firm controls end-to-end. Same code. Same architecture. Same security posture. Same audit trail. Audit-ready out of the box.

30% — the finance customisation

The finance-specific layer is the system prompts (Segment 15), the use case examples (Segments 12 and 14), the weekly-refreshed rate-data file (the same pattern this site uses for sector-data.json), and the capstone project briefs (Segment 28). These swap in via copy-paste — your finance staff take the prompts from Section 3 above and use them where the generic course says "your sector prompt here." The Build Kit also includes finance-tuned versions of: the Multi-Model Compare tool (Segment 13) for cross-checking rates, the System Prompt framework (Segment 15) for FCA-aligned language, and the Final Project rubric for finance-relevant capstone projects.

Why this matters for audit and compliance

Because the underlying technical architecture is identical to every other BUILD cohort, your IT and information security team can review and approve it once, and that approval covers every member of finance who ever takes the course. The finance customisation is purely at the prompt and use case layer — which is where your firm's existing professional judgement lives. Compliance reviews the architecture once. Finance reviews the prompts. The auditor reads both. Everyone stays in their lane.

Section 5

Compliance & regulatory alignment

BUILD for Finance is positioned to help your firm meet (and document) compliance with multiple converging requirements.

FCA Consumer Duty

The Consumer Duty's "fair value" and "consumer understanding" outcomes require firms to evidence that customer communications are clear, fair, and not misleading. Tools your team builds with BUILD generate audit trails (request ID, model used, prompt version, output) that the FCA's Consumer Duty regime explicitly expects firms to maintain.

SM&CR & senior accountability

The Senior Managers & Certification Regime makes individuals personally accountable for the systems they run. "We use a black-box vendor we can't audit" is a much harder defence than "we built it ourselves on infrastructure we control with version-controlled prompts and full audit logs."

EU AI Act (Article 4 + Annex III)

From August 2026, organisations using AI systems must demonstrate "a sufficient level of AI literacy" among staff who operate them. Financial AI systems for credit scoring, insurance pricing, and customer due diligence are also classified as "high-risk" under Annex III. BUILD produces a per-staff-member artefact (live tool, GitHub portfolio, README documentation) that evidences exactly the literacy the Act requires.

Data residency & CASS

Tools built with BUILD use the Cloudflare Worker proxy pattern: API keys never leave the server, requests can be routed through infrastructure pinned to UK or EU data centres, and you can isolate any client data from public AI tools entirely. Materially better than staff pasting client portfolios into ChatGPT.

Equality Act 2010

As employers and as service providers, finance firms are bound by the Equality Act 2010 — particularly in customer-facing communications and product design where indirect discrimination claims can arise. Tools your staff build with BUILD are auditable end to end, which gives the firm a stronger answer than vendor black-box AI if a tool's outputs are ever scrutinised under the protected-characteristic provisions or the Consumer Duty's "fair value" outcome.

⚖ A specific note on PRA / CBI / regulator audits

PRA-supervised firms and Central Bank of Ireland-regulated firms are starting to ask about AI governance directly during s166 reviews and Pillar 2 assessments. "We use the major commercial finance-AI vendor" is increasingly a yellow flag because the firm has no visibility into the model, the prompt, or the data path. "We train our staff to build their own auditable tools running on infrastructure we control, with weekly-refreshed rate data and version-controlled prompts" is a much stronger answer. Several BUILD-graduated firms have used the cohort artefacts in supervisor discussions — we can introduce you to one of them on request.

Section 6

Pricing — for finance teams

Three tiers based on cohort size. All prices are the firm-wide commercial rate, not per-seat consumer pricing. Includes the full BUILD course, the Finance Build Kit, the Manager Pack, weekly rate-data refresh templates, and email support across the rollout.

Pilot Cohort

£4,500 / cohort

Up to 10 finance staff

Full 28-segment BUILD course
Finance Build Kit (5 system prompts)
Weekly rate-data file template
Manager Pack + Capstone rubric
Email support across the 4 weeks
One IT whitelist consultation

Department Rollout

£9,500 / cohort

Up to 25 finance staff

Everything in Pilot
Buddy pairing + cohort kickoff call
Mid-point manager check-in (60 min)
Capstone showcase facilitated by ET
Anonymised cohort Risk Report aggregation
One firm-specific prompt customisation

Firm-Wide

From £18,000

25–100+ staff across multiple offices

Everything in Department Rollout
Multiple parallel cohorts
Train-the-trainer for in-house champion
Custom Finance Build Kit additions
White-label option for internal LMS
Quarterly check-ins for 12 months

All prices ex-VAT. Procurement-friendly invoicing available. Email hello@everythingthreads.com for a tailored quote or to arrange a discovery call.

Section 7

FAQ — for finance team leadership

Can our finance staff actually do this? They're not developers.

That's exactly who BUILD is designed for. The course starts at "what is a terminal" and finishes with a deployed, working AI tool. Across hundreds of non-developer students — including FP&A analysts, compliance officers, and treasury managers — completion rates for cohorts with manager air cover (see the Manager Pack) sit in the 80%+ range. The finance staff who finish BUILD become the in-house AI champions for everyone else.

How is this different from the finance-AI vendors we already use?

Three differences. First, ownership: tools built with BUILD belong to your firm, run on infrastructure you control, and can be modified or retired without vendor permission. Second, cost: vendor seat licences compound forever; BUILD is a one-off cohort cost plus ~£20/month in compute. Third, oversight: your IT team can review the actual code, your finance staff understand exactly what the prompts do, and your auditor has full audit visibility — something the major vendors don't offer at any price.

What about client and customer confidentiality?

The Cloudflare Worker proxy pattern (taught in Segment 11) keeps API keys server-side and routes requests through infrastructure your firm controls. You can deploy with regional pinning to keep data inside the UK or EEA. Critically, BUILD teaches finance staff to think about data flow as a first-class concern — most firms find their staff understand confidentiality and data residency risks materially better AFTER BUILD than before, regardless of which tools they end up using.

Who owns the tools the staff build?

Your firm. The code lives in your firm's GitHub. The infrastructure is provisioned in your firm's accounts. BUILD's terms of service grant the student a perpetual, transferable licence to the course materials and explicitly disclaim any vendor claim on the work product. Standard work-for-hire applies as it would for any other internal development.

What if a staff member builds something that gives bad financial advice?

Every system prompt in the Finance Build Kit explicitly instructs the AI that its output is triage, not advice, and requires the standard "qualified professional must review" disclaimer in every output. The Disclosure Checker prompt specifically refuses to generate financial promotions. The Rate Detector explicitly disclaims tax advice. Segment 24 (Testing Your AI Tools) walks through edge case handling. Segment 27 (Security, Safety & Guardrails) covers the broader risk controls. The tools are designed to support staff judgement, not replace it — and the course explicitly says so, repeatedly.

How does the weekly rate-data refresh work?

We provide a template finance-data.json file that you maintain weekly with current tax thresholds, allowances, Bank Rate, and any other figures your tools need to verify. The Stale Rate Detector reads this file in every request and uses it as ground truth — if a model output contradicts the file, the file wins. Your compliance team owns the file. Total maintenance time: about 15 minutes per week.

How long does the rollout take from kick-off to first cohort?

Typically 2–3 weeks from contract signature to Day 1 of the cohort. Most of that time is IT whitelisting (VS Code, Git, Node.js) and cohort selection. Once the course starts, it runs 4 weeks. Total elapsed time from "we want this" to "we have finance staff with deployed tools" is around 7 weeks.

Should we run SHARP first or go straight to BUILD?

For most finance teams: SHARP first across the whole department, BUILD second for the technically curious subset. SHARP is the AI literacy and risk vocabulary layer — 4 weeks, 2–4 hrs/week, no installs. After SHARP, your finance staff share a vocabulary for AI risk ("that's an M4, the Confident Guess on a stale tax threshold") which makes BUILD's technical content land harder. Combined SHARP + BUILD pricing is significantly better than buying them separately. Email us for the combined tier.

Ready to talk?

If you're a CFO, head of compliance, FP&A lead, or risk & audit lead and you want to bring BUILD for Finance to your team, the next step is a 30-minute discovery call. We'll walk through your current AI use, your regulatory constraints, and which cohort tier makes sense.

Email hello@everythingthreads.com →

EverythingThreads is contact-by-email only. We reply within 2 working days. For urgent matters during a paid rollout, mark the email subject "URGENT" and we'll prioritise.

Sister sector editions: Legal · Education · Healthcare · Governance · Marketing · HR & People Ops · all sectors hub