An enterprise spend platform,
built far enough to be evaluated.

• money movementcorporate cards

  Virtual + physical cards, sub-100ms authorization budget, single-writer ledger holds. Local issuer by default; flip BREXIT_CARDS to lithic-sandbox to drive real Lithic auths.

• money movementbanking

  ACH and wire shaped against the Increase API surface. Local rails settle instantly; the same code paths run unchanged against the Increase sandbox. RTP is on the roadmap, not yet wired.

• money movementbank linking

  Plaid-shaped Linker port. Local adapter seeds 60d of plausible transactions; the Plaid sandbox adapter drops in with one env var swap.

• spend platformbill pay

  Upload-or-API intake (OCR via Mindee adapter), approval chains via the generic approvals engine, vendor records, scheduled payment via the banking rails. Email-to-bill ingestion and check/virtual-card rails are scaffolded but not yet wired.

• spend platformexpense management

  Receipt submission with manual transaction linking, in-house policy engine evaluated in the auth hot path, approval thresholds that fire real workflows. Receipt-to-transaction auto-match and reimbursement payout are on the roadmap.

• spend platformaccounting sync

  QuickBooks-shaped Sync port with per-customer connection state. Local adapter persists journal entries to a fake QBO; the real adapter calls /v3 unchanged.

• in-house enginesfraud decisioning

  Explainable feature-based scorer, runs inside the auth budget, every decision streams into an operator-reviewable queue with the signal breakdown.

• in-house enginesmerchant enrichment

  Exact -> prefix -> substring match against an in-house canonical merchant DB, operator endpoints for alias curation. A dedicated training UI in Sudo is on the roadmap; today operators curate via the API.

• in-house enginescredit underwriting

  Reads linked bank data and produces a tiered decision with reasoning. A/B/C/D/decline based on the section 12.4 formula with industry + stage multipliers. Continuous re-evaluation against fresh bank data is on the roadmap.

what's worth looking at

The architecture is the product.

• 01

  Capability-port architecture

  Every external dependency lives behind a domain-shaped interface. Local, sandbox, and production adapters all implement the same port and are independently selectable per-customer per-capability.

  // internal/ports/cards/cards.go
  type Issuer interface {
      CreateCard(ctx, req) (*Card, error)
      Authorize(ctx, auth) (Decision, error)
      ...
  }

• 02

  Three-tier adapter model

  local · sandbox · production. Most capabilities ship with all three already scaffolded; the sandbox + production tiers are the same code with different env vars.

  BREXIT_CARDS=local            # default
  BREXIT_CARDS=lithic-sandbox   # opt in
  BREXIT_CARDS=lithic-production # gated

• 03

  The authorization hot path

  Card resolve → status checks → fraud score → policy → velocity → ledger hold, serialized per-account via SELECT FOR UPDATE. Sub-100ms p99 target end-to-end.

  // internal/domain/auth_engine
  decision, err := engine.Authorize(ctx, AuthInput{
      CardID:        cardID,
      AmountMinor:   amount,
      MerchantMCC:   mcc,
  })

• 04

  In-house engines for the differentiators

  Fraud, merchant enrichment, credit underwriting, policy, rewards. These are the systems where off-the-shelf vendors either don't exist at the required quality or don't fit the latency budget.

  // internal/domain/fraud
  score := scorer.Score(ctx, AuthInput{...})
  // → 0-100 + confidence + top-3 signals

what isn't built

The honest gap list.

The capability blurbs above describe the shape of the platform; this band describes where the shape stops. If you're evaluating architecture, this is the more useful section. Anything not listed here is either built or honestly labeled in the capability matrix.

what this isn't