This is a portfolio/learning project that scores synthetic transaction data. It has no authentication, no rate limiting, no encryption at rest, and no input origin verification beyond Pydantic's type validation. Do not deploy this against real payment data, real PII, or any production financial system. Nothing below should be read as a claim that this system is hardened for that use — it isn't, and that's by design at this stage (see ROADMAP.md for what closing that gap would actually require).

If you're evaluating this repo for anything other than its own sake — as a hiring signal, as a base for a real project — the honest scope is "the ML scoring core and the streaming plumbing are solid; everything a real deployment needs around them (authn, persistence, network isolation, secrets management, compliance) is not yet built."

This project does not currently follow a formal release/support cadence. Security fixes, if any are reported, will be applied to the main branch. There is no LTS branch and no version currently receives dedicated backports.

This will be revisited once CHANGELOG.md has tagged releases beyond v0.x.

If you find a security issue in this codebase (not "this system lacks auth" — that's a known, documented gap, not a report-worthy finding; see above):

1. Do not open a public GitHub issue for it.
2. Open a GitHub Security Advisory on this repository (preferred), or email the maintainer directly if the advisory feature isn't enabled.
3. Include: what you found, how to reproduce it, and what you think the impact is. A PR with a fix is welcome but not required to file the report.

Expect an acknowledgment within a few days. This is a single-maintainer portfolio project, not a company with an SLA — response time will be best-effort.

These are documented limitations, not surprises:

• No authentication on any endpoint. POST /score, /score/batch, /stats, and /ws/live are all open. Anyone who can reach the port can score transactions and read aggregate stats.
• No rate limiting. /score/batch caps at 500 items per request at the application layer, but nothing prevents a client from calling /score in a tight loop.
• CORS is wide open (allow_origins=["*"] in api/main.py) — intentional for local development, called out explicitly there and here so it isn't shipped unnoticed. A real deployment must restrict this to known origins.
• No secrets in this system currently — there's nothing to leak (no API keys, no DB credentials, no third-party tokens). If Postgres/Redis are added per RFC-0001, this section gets a real "secrets management" subsection; until then, there's genuinely nothing here.
• Kafka has no authentication or TLS configured in docker-compose.yml — plaintext listeners, appropriate for local Docker networking only. Do not expose the Kafka ports beyond localhost/the Docker network.
• The model and its calibration are trained on synthetic data. Even if this system's security posture were hardened, the model itself has not been validated against real fraud patterns and should not be relied on for actual fraud decisions.

requirements.txt pins exact versions (see AGENTS.md). Dependabot or an equivalent isn't currently configured; if you're picking up work in this repo, adding basic dependency vulnerability scanning (pip-audit in CI, once CI exists — see ROADMAP.md) is a reasonable, low-scope contribution.

For anyone using this as a checklist of what a real deployment needs on top of what exists — this is intentionally not built yet, tracked here rather than silently assumed:

• Auth on every endpoint (API keys at minimum; OAuth2/mTLS for service-to-service in a real deployment).
• Secrets management for any credential introduced by RFC-0001 (Postgres, Redis) — not plaintext in docker-compose.yml.
• TLS on the Kafka listeners if the broker is ever reachable outside a trusted network.
• PII handling review before any real transaction data (even tokenized) touches this system — this repo currently has none, and that's a feature, not a gap, until there's a real reason to change it.
• An actual threat model for the fraud domain specifically: an adversary here isn't just trying to breach the system, they're trying to get fraudulent transactions scored as legitimate. That's a different (and harder) problem than standard web app security, and it isn't addressed by anything in this list.