Now shipping · Preston-Check 1.0

Analytical engines
for systems that can’t fail.

AnalyticLab builds AI-augmented developer tools for fintech and other regulated industries — software that turns post-mortems into prevention, and compliance into something you can run from the command line. When an incident is already underway, we send the team that wrote the checks.

0
Automated checks
0
Compliance frameworks
0
Session traces analyzed
$0
Free tier, forever

What we do

One catalog. Two ways to put it to work.

The same 294-check catalog either runs in your pipeline before every deploy, or arrives with a team when something has already gone wrong.

Track 01 · Software

Preston-Check

The catalog as a tool you run yourself. Install it, point it at a repository, and gate your pipeline on the result. No account, no upload, no consultant.

  • 294 automated checks across 33 reputable frameworks
  • Runs locally — source files never leave your environment
  • Exits non-zero on failure, so CI can block the deploy
  • Free tier is the full catalog, forever
Explore the full offering
Track 02 · Engagement

Incident Intervention Team

The catalog as people. When a financial system is under attack or has just been breached, we mobilize, reconstruct what happened, contain it, and leave the findings behind as checks that run forever.

  • Same-business-day response, then a triage call that sets scope and severity
  • Forensic reconstruction from session, request, and ledger data
  • Written timeline your regulator and your board can both read
  • Your incident compiled into custom checks in your pipeline
How an engagement works

Track 01 · The product

Pre-deployment security, run locally — augmented by AI.

Preston-Check is fintech-narrow on purpose. The catalog is 294 checks built from real production audits, not fifty thousand generic patterns crawled from public repositories. Lower noise, higher signal, and a report your auditor will actually read.

Live · Apache 2.0

Preston-Check

Pre-deployment security audit for fintech. 294 automated checks spanning 33 reputable frameworks — from PCI-DSS and SOC 2 to MiCA, DORA, OWASP, and post-quantum FIPS standards. Runs locally in seconds. Your code never leaves your machine.

  • Local-first: source files never leave your environment
  • AI-augmented findings & suggested patches (--ai-fix)
  • CI-ready: GitHub Actions, GitLab CI, CircleCI, pre-commit
  • Free for OSS & small teams · zero account required

Coverage by domain

Every check cites the framework control it stems from, and where applicable the real-world incident that motivated it. Filter a scan to a single regulator with --framework and hand the scoped report to the auditor who asked for it.

Card payments
PCI-DSS v4.0PCI 3DSEMVCo 3DS 2.x
EU finance
MiCA 2024TFR 2023PSD2PSD2-RTSDORA 2025
US finance
NYDFS Part 500FinCEN 31 CFROFAC SDN
Asia-Pacific
MAS TRMAPRA CPS 234RBI CSF
AML & sanctions
FATF 2023Travel Rule Rec. 16
General security
SOC 2 (TSC 2017)ISO 27001:2022ISO 22301:2019
OWASP families
API Top 10 2023Top 10 2021Mobile MAS 2024LLM 2025Smart Contract 2025
NIST family
NIST CSF 2.0FIPS 203/204/205SSDF 1.1
Crypto custody
CCSS v9.0 · L1–L3
Cyber benchmarks
CIS Controls v8

The catalog

294 checks where each one has a name, a story, and a citation — grouped into suites you can run whole or in isolation.

P-01 → P-10

Core attack patterns

Hardcoded secrets, 2FA bypass, information leakage, rate limiting, idempotency, session security, blacklist evasion, input validation, audit trail, live attack indicators.

P-11 → P-20

Platform security

TLS and weak crypto, financial guards, auth enforcement, vulnerable dependencies, CORS/CSRF, error handling, secure random, data privacy, API versioning, deployment safety.

P-21 → P-56

Enterprise suite

Card data handling, AML monitoring, KYC document security, AWS IAM hygiene, WAF and DDoS, webhook signatures, BOLA, mass assignment, SSRF, key management, container and CI/CD security.

P-57 → P-64

Compliance gap coverage

Business logic abuse, vulnerability scan evidence, security policy documentation, email security, privacy and consent, pentest evidence, supply chain risk, recovery testing.

P-65 → P-82

Financial controls

Transaction velocity, dormant accounts, money-mule detection, fee manipulation, exchange rate safety, settlement finality, beneficial ownership, sanctions screening, proof of reserves, ledger consistency.

P-83 → P-95

Evidence verification

The artifacts auditors actually ask for: organizational policies, security training, physical access records, disaster recovery, asset inventory, vendor assessments.

P-301 → P-360

Crypto & DeFi

Smart contract security, key custody and ceremonies, outbound transaction safety, withdrawal whitelisting, mixer detection, tainted-funds tracing, CCSS evidence, post-quantum readiness.

P-400 → P-415

Resilience & state regulators

DORA ICT risk framework, incident reporting timelines, threat-led pentesting, third-party register, RTO/RPO — plus the NYDFS Part 500 program, CISO designation, and expanded MFA scope.

P-420 → P-437

Mobile & LLM surfaces

The OWASP Mobile Application Security suite for iOS and Android, and the OWASP LLM Top 10 for fintechs running chatbots, document processing, or model-driven fraud detection.

P-440 → P-483

Regional regulators & payment auth

MAS TRM, APRA CPS 234 with its 72-hour notification, RBI Cyber Security Framework, the PSD2 strong-customer-authentication suite, and PCI 3DS / EMVCo 3DS 2.x.

P-490 → P-504

Polyglot code checks

OWASP Top 10 patterns applied across languages, including memory-safety concerns such as Rust unsafe blocks.

Community

Proposed & verified

Contributed checks move through a trust-tier system — proposed, accepted, then field-verified. Run the unreviewed edge with --include-proposed; author attribution shows in every report.

How it runs

One surface across every environment. The same exit codes and the same Markdown report whether you run it as a CLI, a GitHub Action, a GitLab or CircleCI job, a Docker image, or a pre-commit hook.

1

Install

Homebrew, Docker, a shell installer, or a pinned GitHub Action. No account and no license key for the free tier.

$ brew tap preston-check/tap $ brew install preston-check
2

Scan

Scope the run by severity, framework, or check type. A critical-only pass finishes in about twelve seconds; a full scan takes thirty seconds to three minutes.

$ preston-check --high-and-up \ --ci --report audit.md
3

Gate

In CI mode the scan exits non-zero on any failure, so a blocking finding stops the deploy instead of becoming a ticket nobody reads.

# fails the build on any FAIL $ preston-check --critical-only --ci

Plans & pricing

Every software tier gets the complete 294-check catalog — what you pay for is the evidence layer around it. Incident work sits alongside them rather than inside them, because it is scoped to the incident rather than to a repository count.

Free
$0

No signup, no account, unlimited repositories.

  • All 294 checks, every framework
  • Markdown and local PDF reports
  • AI augmentation with your own API key
  • Every CI integration and the airgap mode
Enterprise
$29,999+ / year

For regulated institutions with auditors of their own.

  • Everything in Pro
  • White-label dashboards and reports
  • SSO via SAML or OIDC
  • Custom check authoring and signed audit packages
  • On-premise deployment and SLA-backed support

OSS exemption. Any repository with a recognized open-source licence — MIT, Apache, BSD, GPL, MPL, ISC — gets Pro features automatically and free. This is deliberate: a fintech maintaining an open-source library shouldn’t pay to scan it, and public security work makes everyone safer.

In development
Continuous compliance evidence
Auto-generated, signed audit packages for SOC 2, ISO 27001, PCI-DSS — refreshed on every push.
Researching
Anomaly detection for production traces
Apply the same analytical lens to live session and request data — catch attackers in flight.

Track 02 · The team

When it’s already happening, we come in.

Preston-Check exists because of an incident nobody caught in time. The Incident Intervention Team is the other half of that lesson — a small engineering team that mobilizes on a live or recent breach in a financial system, reconstructs it from the data, contains it, and leaves the findings behind as automation.

We are not a retained security vendor and we do not sell fear. We are the engineers who spent months inside a fintech breach reading session traces line by line, and who turned that post-mortem into 294 automated checks. When your system is the one under attack, that is the work we do again — on your data, with your team, in your codebase.

Call us when
  • An attacker is active right now and you need the path closed
  • Funds moved in a way your controls should have stopped
  • You found the breach late and the logs are close to rotating out
  • A regulator’s notification clock has started and the timeline has to be defensible
  • The incident is contained, but nobody can yet explain exactly how it happened

How an engagement runs

Five phases. The first one is a conversation, not a contract — we scope the incident before anyone signs anything.

Hour 0 – 4

Triage

A call with your engineers rather than a questionnaire. We establish blast radius, whether the attacker still has access, and what has to stop moving immediately. The output is a written scope and severity you can take to your board the same day.

Hour 4 – 48

Containment

Close the path, revoke what needs revoking, and preserve evidence before logs rotate out of retention. Every containment decision is recorded as it is made, because the sequence of your own response is part of the timeline you will later have to defend.

Day 2 – 10

Forensic reconstruction

Rebuild the attack from session traces, request logs, and ledger movements until the account of what happened is complete rather than plausible. This is the same method that produced the 1.3-million-trace corpus behind Preston-Check.

Day 5 – 15

Hardening

Fix the class of defect, not only the instance that was exploited. Every patch is reviewed against the 294-check catalog, so the remediation does not quietly open something adjacent while closing the thing that hurt you.

Handover

The incident becomes a check

A written post-mortem, a notification-ready timeline, and custom checks authored from your incident and wired into your pipeline — so the same attack fails in CI the next time anyone tries it. That is the whole point: the lesson outlives the engagement.

What you keep

Everything we produce is yours, in formats your engineers, your executives, and your regulator can each read without needing a different version of the truth.

Incident timeline

Hour-by-hour reconstruction of what the attacker did, what your systems did, and where the two diverged from what you expected.

Evidence package

Preserved and hashed artifacts — the log extracts, traces, and database state that support every claim in the timeline.

Containment record

Every change made during the response, when it was made and why. The audit trail for the response itself, not just the breach.

Notification summary

Mapped to the clauses that set your clock — DORA reporting timelines, the APRA CPS 234 seventy-two-hour rule, NYDFS Part 500.

Custom checks

Your incident compiled into Preston-Check checks that run in your pipeline permanently, with the finding written in your own vocabulary.

Engineer handover

A working session with your team so the understanding stays in your building after we leave, rather than leaving with us.

Pricing is scoped to the incident.

There is no rate card here, and that is deliberate. A two-endpoint webhook replay and a multi-week custodial breach are not the same engagement, and publishing one number for both would mean quoting one of them wrong. Scope is established on the triage call, and a fixed-fee proposal follows it in writing before any billable work begins.

Reaches incident@analyticlab.io — a dedicated address, kept separate from general enquiries. We respond the same business day. The triage call itself is how we both find out whether we are the right team for what you are facing.

What determines scope
  • Severity, and whether the attacker still has access to anything
  • How many services, ledgers, and environments are in play
  • Whether the evidence has to hold up to a regulator or an external auditor
  • How much of the remediation you want us to implement rather than hand over
  • Whether the work ends at handover or continues as standing coverage

Our approach

Four principles, every product.

We build for engineers who already have audit fatigue. The work has to be fast, private, and grounded in real attacks — not vendor checklists.

Local-first

Your source code never leaves your machine. Airgap mode is one flag away.

AI-augmented

Findings get LLM analysis and suggested patches when you opt in — never required.

Compliance-mapped

Every check ties back to a clause: PCI-DSS, SOC 2, MiCA, DORA, NYDFS, ISO 27001.

Open by default

Apache 2.0 core. OSS repos get pro features free. Verify the code yourself.

Provenance

Every check started as an attack that worked.

The catalog is named after Preston X, a real attacker on a production fintech platform. It is the post-mortem of his attack, turned into automated regression tests.

In February 2026 he created more than five accounts with synthetic names and disposable numbers, set two-factor authentication to none on all of them, and ran 21,201 automated calls against a single configuration endpoint at one- to two-second intervals. The session responses leaked third-party API keys, the platform’s fee structure, and internal permission flags. He moved on to credential stuffing, registered again using a stolen payment-API key after being blacklisted, then probed custodial withdrawals with deliberately wrong two-factor codes to map the balance checks.

Every one of those steps is now a check. And because each finding pattern was tested against the full forensic corpus — real traffic from both the attacker’s accounts and the platform’s legitimate users — before being promoted into the catalog, the false-positive rate is meaningfully lower than scanners calibrated only against synthetic test fixtures. That corpus is also why the Incident Intervention Team knows what a live attack looks like in the logs: we have already read one, end to end.

21,201 Automated polling calls against one configuration endpoint
1.3 M+ Logged session and request traces in the forensic corpus
2FA: none The setting on every account the attacker created
294 Checks the post-mortem eventually produced

Questions

The things people ask first.

Does our source code ever leave our machines?

No. The scanner reads local files and reports locally. The only network call it can make is opt-in anonymous score telemetry that feeds the annual State of Fintech Security report, and --airgap blocks even that. The scanner is Apache 2.0, so you can verify this claim yourself rather than taking our word for it.

What does it cost to start?

Nothing. The free tier is the complete 294-check catalog across unlimited repositories, with no signup, no account, and no licence key. Paid tiers add the evidence layer around the scanner — branded reports, multi-repo dashboards, and signed audit packages — not extra checks. Repositories with a recognized open-source licence get Pro features free.

How long does a scan take?

A critical-only pass finishes in roughly twelve seconds and light mode in four to thirty seconds, which is fast enough for a pre-commit hook. A full scan of a typical fintech codebase takes thirty seconds to three minutes depending on size and severity filter.

Is the AI required?

No. Every check is deterministic and runs without a model. AI augmentation is opt-in through --ai-augment for finding analysis and --ai-fix for suggested unified-diff patches, and it uses your own Anthropic or OpenAI key. Nothing about the scan depends on a model being available, or on us.

Do we have to send you data to get incident help?

Not to start. Triage begins with a call, and evidence handling is agreed in writing before anything moves. For many engagements the analysis runs inside your environment on your infrastructure, which is usually the right answer when the data in question is the same data a regulator will ask about later.

Can the intervention team stay on afterwards?

Yes. Engagements can end at handover or continue as standing coverage on a retainer, which is generally the right shape when an institution has just discovered that its detection was the part that failed. That decision comes after the incident work, not bundled into it.

Talk to us.

Working on a hard analytical problem in fintech, crypto, or a regulated industry?
Or dealing with one right now? We’d like to hear about it.