BIN Oracle Scan: find the 3DS pre-authorization leak in card checkouts
Tests card checkouts for 3DS flows that leak BIN routing to card testers. Payfacs and PSPs pay.
Early · 3DS Oracle paper names the leak
Written for: Small startup team
Next step
Call the head of payments risk at a mid-size payfac such as Finix and ask how many card-testing incidents last quarter came through 3DS-enabled checkouts, and whether they would authorise a scan of their five main integration patterns.
Why now
The leak is now described in public, so card testers can read the paper too. Card testing is already a budgeted fraud and chargeback cost at every PSP. Checking for the leak needs only browser automation and test cards, which suits a software-only team that knows payments. The fix often sits in how the PSP or payfac wires up its 3DS server, not in the EMVCo spec, so there is something the customer can change once they know where the leak is.
What became possible
The 3DS Oracle paper shows that EMV 3-D Secure needs a client-visible continuation step in browser flows. In some deployments that step reflects routing and authentication status before authorization, which gives attackers a way to classify cards for BIN attacks. The authors back this with standards analysis, formal modelling, a documentation audit, disclosure history and a bounded live evaluation.
Three ways in
- BIN Oracle Scan
An authorised headless-browser scanner. It runs a PSP's own integration patterns (hosted fields, redirect, SDK) through 3DS with a matrix of test BINs and measures whether anything visible to the client (redirect shape, timing, response codes) changes with route or enrolment status. The output is a per-pattern leak report with fixes.
- Customer
- Fraud and payments-risk teams at mid-size PSPs and ISV payfacs
- Model
- Fixed-fee audit per integration pattern, then an annual subscription that re-runs on every checkout release
- Oracle Mute
A thin wrapper around the 3DS client step that normalises the timing and response shapes visible to the client, so a checkout reveals nothing until authorization.
- Customer
- ISV payfacs running their own checkout front ends
- Model
- Per-merchant monthly licence
- Enumeration Watch
Detection rules for the request patterns that oracle-style BIN probing produces against 3DS endpoints, shipped as a rule pack for existing fraud tools.
- Customer
- Merchant fraud teams at high-volume card-not-present merchants
- Model
- Rule-pack subscription
Competition
I found no product, open-source tool or published research that runs authorised scans of a PSP's own 3DS integration patterns (hosted fields, redirect, SDK) to check whether timing, redirect shape or response codes reveal BIN routing or enrolment status before authorization. The market is full of reactive card testing detection from cside, HUMAN, FraudNet, FIS, Ravelin and built-in PSP tools such as Stripe Radar and Cybersource.
Full competition notes (8 competitors)
I found no product, open-source tool or published research that runs authorised scans of a PSP's own 3DS integration patterns (hosted fields, redirect, SDK) to check whether timing, redirect shape or response codes reveal BIN routing or enrolment status before authorization. The market is full of reactive card testing detection from cside, HUMAN, FraudNet, FIS, Ravelin and built-in PSP tools such as Stripe Radar and Cybersource. Sandbox test cards from Stripe and Mercado Pago only check that an integration works, and FIME's simulator is for physical card terminals. So BIN Oracle Scan has a real opening as a security assessment for mid-size PSPs and ISV payfacs, priced per integration pattern and pitched around Visa's enumeration guidance and VAMP thresholds, which put the burden on acquirers and processors. The main risks are that sandbox BINs may not reproduce real routing or enrolment behaviour, so meaningful scans may need live access with PSP and network permission, and that the market of mid-size PSPs is small enough that this may become a consulting product. Oracle Mute has no direct competitor I could find, but big PSPs and 3DS server vendors could easily build it themselves, so it probably works best as the fix sold with the scan. Enumeration Watch enters a crowded detection field and would be hard to tell apart from what merchants already have.
- cside
Detects card testing and BIN attacks in the browser layer (session, device and behavioural signals). It is detection, not testing an integration for 3DS leaks, so it competes directly with Enumeration Watch.
- HUMAN Security Sightline (transaction abuse defense)
Detects bot-driven carding with blocks, honeypots and misdirection. Overlaps with Enumeration Watch, and partly with Oracle Mute's misdirection idea, but does not audit 3DS flows.
- FraudNet
Detects enumeration at the BIN-range level across merchants and pitches it around Visa VAMP thresholds. A detection competitor.
- FIS card enumeration fraud solution
Detects enumeration patterns across issuers, merchants and networks. Network-scale detection, not checkout leak testing.
- Stripe Radar
Built-in card testing defences. Stripe's docs say testers collect 3DS or issuer responses to validate cards, which confirms the threat, but Stripe offers no external leak scanner.
- Cybersource / Visa Acceptance card testing solution
Built-in card testing controls on the PSP side. Shows that large PSPs build defences themselves.
- Payrix card testing best practices
Payfac guidance on failed-authorization rules and rolling API keys for hosted payment pages. Configuration advice, not a scanner.
- Cardinal Commerce BIN Detection
A legitimate 3DS feature that runs issuer device profiling before authentication. Not a competitor, but the name clashes with the BIN Oracle branding.
Checked 2026-10-26
Risks
- Scanning merchants without the PSP's written authorisation is a legal problem, so this must be sold top-down
- The paper's live evaluation was bounded, so how common the leak is remains unknown
- Some leaks sit in 3DS server vendors' products, which the customer cannot change quickly
- Large PSPs may patch this internally and never buy a tool
Strong team fit; tech readiness and market pull and buildability are the weak point (7).
tech 7 · pull 7 · space 8 · fit 9 · build 7
Exposed
Companies that could benefit or be threatened. News and context, not investment advice.
Momentum of its main topic
Sources
Status history
- 2026-10-26 Flagged as buildable