New Release
Typed Schema Fields and Data-Classification Markers
Custom schema fields now declare a type from a closed vocabulary — fromemail, iban, and phone to amount, pan, and masked-pan — and
Specter validates incoming payloads against it at ingestion: Luhn checks
for card numbers, ISO 8601 for dates, check digits for IBANs, closed enums
for schemes and funding types. Each field also carries a data-classification
marker (pci-pan, pci-sad, pii, or none) that governs where its value
may flow: marked values are redacted from error bodies, logs, and audit
events, pan fields are always PCI-scoped, and sensitive authentication
data is never stored — below SAQ-D it is rejected outright, and nothing
that persists data (velocity counters, blacklist entries) may reference a
pci-sad field.New Release
Built-In Transaction Schema
The decision payload shape Specter ships with is now a first-class schema: read-only, introspectable through the schema registry like any custom schema, and evolving additively only — existing fields never change type or disappear. Rulesets that name no custom schema are backfilled to bind the built-in, so every ruleset now states what it evaluates against.New Release
BIN Attributes on Card Credentials
Card credentials now expose BIN-derived attributes —bin, schemes,
type, segment, currency_code, issuer_name, and
issuer_country_code — on both credential.pan and
credential.masked_pan, ready to use in rule conditions. All attributes
are optional and reflect the BIN data as provided: Specter does not curate,
reconcile, or guarantee consistency between them. schemes is an array —
match it with the in operator. When simulation detects diverging BIN
attributes, the trace carries a bin_attribute_divergence warning.New Release
Custom Decision Schemas
Define the shape of your own decision payloads with the new schema registry under/api/admin/schemas. Schemas are named and versioned: a draft version
is editable, a published version is immutable, and a superseded version can
be deprecated while it keeps serving the rulesets bound to it. A ruleset
binds one published (schema, version) pair — the binding validates
incoming payloads and resolves rule field paths. The identity fields of a
persisted ruleset (schema, context) no longer change on PATCH:
sending a different value returns a 422, resending the same value is a
no-op.The registry endpoints require the new admin:schemas:read and
admin:schemas:write scopes.New Release
Filter Pipes and HMAC Fingerprints in Rule Conditions
Field references in rule conditions now accept filter pipe chains —$.customer.email | trim() | downcase() — wherever a field path appears:
condition operands, velocity fields, and HMAC inputs. The v1 filter set is
closed and typed; filters compose left to right, and a filter receiving an
absent or malformed value abstains rather than failing the rule. Filtered
values inherit the strictest data-classification marker of their inputs.A new hmac operator composes an ordered list of filtered field references
into a deterministic HMAC-SHA256 fingerprint, so rules can correlate on
stable derived identifiers without exposing the underlying values.New Release
Simulate Rulesets Without Side Effects
The newPOST /api/admin/rulesets/{id}/simulate endpoint evaluates a test
payload you supply against any persisted ruleset — DRAFT, ACTIVE, or
INACTIVE — and returns a full evaluation trace: the verdict the ruleset
would reach, and for every rule whether it fired, abstained, or was skipped,
and why. Simulation is inert — no decision is recorded, no velocity counter
is incremented, and no backend is invoked. Velocity conditions read live
counter state and report the value they evaluated against alongside the
rule’s threshold and rolling window, so the trace shows how close a rule
was to firing.Simulation requires the new admin:rulesets:simulate scope.New Release
PayPal Payment Method Type
Decision requests now accept apaypal credential alongside pan,
masked_pan, and sepa. The credential carries email, payer_id,
address_status, protection_eligibility, and payer_status — all
optional, all caller-injected from your PayPal flow, and all addressable in
rules as $.credential.paypal.*. Send whichever your flow has captured at
the point you call Specter. The email is never persisted raw; the decision
log keeps the credential fingerprint (computed from payer_id) and a masked
form. See
Credential types.Improvement
Report Fraud on Any Decision
fraud_report events are no longer tied to the payment lifecycle: they are
accepted in any payment state — including for decisions that never received a
lifecycle event — so you can feed fraud signals back to Specter even if you
only use it for screening. An accepted report sets a permanent fraud marker on
the decision (fraud_marked_at, fraud_source, fraud_reason), independent
of payment_state, and continues to fan out to backends and auto-populate the
blacklist. See
lifecycle events.Improvement
Smarter Condition Fields in the Rule Editor
The rule editor’s condition field suggestions are now served by the backend, so the type-ahead always matches the exact request shape your rules evaluate against — including nested credential fields and your$.metadata.* paths.
Fields that are unavailable on your instance, such as raw PAN paths below
SAQ-D, are omitted automatically.New ReleaseImprovement
Run Specter Within SAQ A and SAQ A-EP Scope
Specter now runs on instances assessed at SAQ A or SAQ A-EP — you no longer need a SAQ-D environment to use it. Below SAQ-D, Specter actively enforces the boundary that keeps your assessment scope small: request bodies carrying a raw card number (PAN) outside the designated credential field are rejected with a422 validation error, and Interceptor payloads are scanned so raw
card data never reaches your instance.The platform test-card policy applies on every instance: on the Test tier,
decision requests accept only known test cards; on the Production tier, test
cards are rejected. Violations return a 403 with a clear classifier.New Release