GateShadow — shadow before enforcement
Send your current decision alongside ours for 30 days: agreement matrix, where we are stricter, where looser.
On this page
What it does
Every tenant starts in shadow mode: KYTGate decides and records, you keep deciding. Send your own decision with each screening — or attach it later once your process concluded — and GateShadow builds the agreement matrix: where the two agree, where we are stricter, where we are looser, potential false positives (we REVIEW, you ALLOW) and potential misses (we ALLOW, you BLOCK).
Each disagreement is listed with the rules that fired and the coverage gaps behind it, so the tuning conversation is about specific decisions, not a percentage.
Why a broker needs it
Nobody should switch a funding gate on blind. The false-positive rate that matters is the one on your own traffic, and the only way to know it is to run both systems on the same real events for a while. Enforcement is switched on only when you have seen the numbers.
How it works
Include shadow: { yourDecision, yourReason?, yourProvider? } (ALLOW | REVIEW | BLOCK | REJECT) on the screening request, or POST it to /api/v1/screenings/{id}/shadow afterwards. Your decision never influences ours. GET /api/v1/shadow?days=30 and the console return the matrix. Every response and webhook carries mode and enforced, so the integration is wired once. When ready, your admin flips the tenant to enforce in the console (audited); from then on REVIEW / BLOCK / HOLD mean "hold the funds".
What it does not do
Shadow mode does not hold funds and does not announce SLA breaches; cases still open, for comparison only. It does not tell you which side is right — a disagreement is evidence that two processes differ, and the listed rules and coverage gaps are what you tune the policy on.
API
POST /api/v1/screenings
{ …, "shadow": { "yourDecision": "ALLOW", "yourReason": "processor approved", "yourProvider": "acme-pay" } }
GET /api/v1/shadow?days=30
{ "total": 412, "withShadow": 398, "agree": 367, "weStricter": 27, "weLooser": 4,
"potentialFalsePositives": 27, "potentialMisses": 4, "matrix": { "REVIEW": { "ALLOW": 27, … } },
"disagreements": [ { "screeningId": "…", "ours": "REVIEW", "yours": "ALLOW", "firedRuleIds": [ … ], "coverageGaps": [ … ] } ] }Full reference: /docs#onboarding · OpenAPI 3.1