How we used EVS out-of-wallet questions as a step-up identity check, what the IRS requires of KBA, and where knowledge-based authentication falls short.
Key findings
We use EVS out-of-wallet questions (dynamic KBA) as a second, independent identity factor on top of a document-and-selfie check, not as a replacement for it.
Questions are generated fresh from public and commercial records and graded on our own server; a pass needs at least 3 of 4 correct within a time limit.
KBA is sometimes mandatory: the IRS requires identity verification for remote e-signing of Forms 8878/8879, and many states require dynamic KBA for remote online notarization.
KBA's known weakness is that the answers are in breached data. The 2017 Equifax breach exposed ~147.9M identities, ~61% of enterprises have cut back KBA since 2021, and NIST discourages it as a standalone authenticator.
A "no match" - when EVS cannot build questions from a person's details - is treated as an identity mismatch and flagged, so the failure is a signal, not just an error.
A stolen ID can pass a document check. It is much harder to fake a lifetime of small facts about a person. This is how we used EVS knowledge-based authentication as a second identity factor, what regulators like the IRS actually require of it, and why KBA is a layer rather than a foundation.
Why add knowledge-based authentication on top of a document check?
Knowledge-based authentication adds the one thing a document check cannot: proof the person knows the private history behind an identity, not just that they hold a genuine-looking ID. A document-and-selfie check confirms an ID is real and that the face matches it, but it cannot test private knowledge, and a convincing stolen ID can clear it on its own. When money is on the line and identity theft is a constant threat, that gap is the whole problem.
Knowledge-based authentication (KBA) closes part of that gap by asking questions only the genuine person should be able to answer. The platform wanted a second, independent kind of check - not another look at the document, but something a fraudster holding someone else's ID would still fail - to raise the bar before it trusts an identity for high-value actions.
At DesignKey Studio, we framed KBA deliberately as a step-up and second factor, never as the whole identity decision. That framing matters for two reasons covered below: in some flows KBA is actually required by regulation, and in all flows it has a real weakness that means it should reinforce a stronger check rather than carry the decision alone.
What is EVS knowledge-based authentication, and when is it required?
EVS (Electronic Verification Systems) is an identity-verification provider, and this integration uses one part of its offering: dynamic knowledge-based authentication, delivered through its IdentiFraud Consumer+ product, the "out-of-wallet" questions you have probably hit when resetting access to a financial account. Using a few basic details, EVS pulls from public and commercial records and generates multiple-choice questions about the person's own history, such as past addresses. The real person can usually answer without thinking; someone who only stole an ID usually cannot. These differ from "security questions" a person picks for themselves: out-of-wallet questions are generated fresh, change every time, and were never set in advance.
The regulatory backdrop is the reason KBA still matters even as alternatives mature. According to the IRS, identity verification including knowledge-based authentication is required when a taxpayer e-signs Forms 8878 or 8879 remotely rather than in the preparer's physical presence. Many states require dynamic KBA as part of remote online notarization. The ESIGN Act and UETA, which make electronic signatures legally valid, do not mandate KBA, but they require a signature to be attributable to a person, and KBA is one accepted way to establish that attribution.
Standards bodies set the ceiling on how much weight KBA should carry. NIST SP 800-63 permits knowledge-based verification only as a supplementary check at identity assurance level 2 (IAL2) and does not allow it at the higher IAL3, and NIST discourages KBA as a standalone authenticator. The practical reading: KBA is legitimate and sometimes required, but it is designed to support a primary identity check, not to be one. That is exactly how we deployed it.
What did we build?
After the document-and-selfie identity step, the platform asks a short set of out-of-wallet questions. The person answers a handful of multiple-choice questions drawn from their own records; answer enough correctly and they are through. Because the questions come from data a fraudster would not have, and change every time, they are a meaningful second hurdle rather than a formality. A useful side effect: if EVS cannot generate questions because the person's details do not match records, that mismatch is itself a signal worth catching early.
An out-of-wallet question: generated from records, easy for the real person, hard for a fraudster.
Generating the questions
The platform sends EVS the details needed to find the right records - name, address, date of birth, and SSN. EVS returns a set of multiple-choice questions, each with its answer options. If the details do not match records well enough to build questions, EVS signals this with a specific "no match" outcome, and the platform treats that as an identity mismatch rather than letting the person through. The absence of a question set is itself information.
Scoring on the server, under a time limit
EVS returns the questions with the correct option flagged. We keep the questions and answers on our own server and grade the submission there, never trusting the browser to grade itself. A pass needs most answers right - at least three of four - and the question screen has a time limit so the set cannot be left open and researched. We expire the set on the server rather than trusting a client timer, and we never send the correct answers to the browser: it submits only the chosen option IDs, which the server compares against the flagged answers it stored. That keeps grading tamper-proof even if someone inspects the page or replays the request from a script.
Where it fits, and what happens if it does not pass
The questions run as a second factor alongside the document-and-selfie check, not as a replacement and not only when that check fails. The same mechanism doubles as a lighter step-up check elsewhere, with fewer questions, when the platform wants extra assurance it is the right person. Genuine people sometimes miss, because records can be stale or a question is ambiguous, so the platform allows a couple of attempts and then falls back to manual document review rather than a dead end.
Tuning the pass bar and the thin-file problem
The hardest tuning question is where to set the bar. Too lenient and the second factor adds little; too strict and you fail real people whose records are stale or sparse. We settled on at least three of four correct within the time limit, a common KBA threshold, and treated it as a dial we could adjust by risk level rather than a fixed rule, so a lighter step-up uses fewer questions and a lower bar. The thin-file case needed its own answer: people with little US credit or public-record history, such as recent immigrants or young adults, can trigger a "no match" not because they are fraudulent but because EVS has too little to build questions from. Routing those to manual review instead of rejection keeps the check from quietly penalizing legitimate users with short records, which is both a fairness issue and, for a regulated product, a fair-lending one.
KBA as a step-up layer: a second factor with three outcomes, none of them a dead end.
Where did EVS KBA excel?
As a second factor, it does something a document check structurally cannot: it tests private knowledge, so one convincing fake is not enough on its own. Pairing "something you have" (a genuine-looking document) with "something you know" (your own history) raises the bar against the exact attack a document check misses, an impersonator holding someone else's ID.
It is also low-friction and broadly reachable. KBA needs no special hardware, no app, and no selfie retakes in bad lighting, so it works as a quick step-up almost anywhere, including for users who would struggle with a biometric capture. Server-side grading under a time limit keeps it honest: answers are scored on our infrastructure, the browser never declares itself passed, and a set cannot be left open and researched. Key takeaway: as a layered, low-friction second factor, KBA caught the impersonation gap cheaply, which is exactly the job we gave it.
Where did it struggle?
The fundamental weakness of KBA is that its answers increasingly live in breached data. The 2017 Equifax breach exposed roughly 147.9 million identities, and large security-question dumps such as Yahoo's mean past addresses, loan amounts, and similar facts may already be in a fraudster's hands. That erosion is measurable: industry reporting indicates about 61% of enterprises have reduced or eliminated KBA since 2021, and NIST discourages it as a standalone authenticator. We treated dynamic KBA as stronger than static security questions, but not as immune, which is why it never carries an identity decision by itself.
The day-to-day friction is false negatives for real people. Records go stale, addresses are ambiguous, and a legitimate user can miss enough questions to fail, so limited retries and a manual-review fallback are mandatory, not optional. The "no match" case needs a deliberate policy too: it can mean fraud, but it can also mean a thin file or a recent immigrant with little US record history, so flagging it for review is more honest than treating every no-match as a rejection. Used as a sole gate, KBA would both miss prepared fraudsters and block genuine users; used as a layer, it earns its place.
What are the alternatives to KBA?
The main alternatives we weighed were biometric liveness, FIDO2 passkeys, and SMS one-time passcodes, alongside the document-and-selfie check KBA already complements. Biometric liveness is the strongest against impersonation because it checks a live face rather than stealable knowledge, at the cost of more friction and a camera. FIDO2 and passkeys are cryptographically phishing-resistant and excellent for repeat logins, but they verify a device or key, not a first-time identity, and require enrollment. SMS OTP is familiar but the weakest of the set, exposed to SIM-swap and interception, and is better thought of as a convenience factor than an identity check.
KBA's niche among these is being instant and hardware-free, which makes it a sensible step-up and a fit where regulation specifically calls for knowledge-based verification. The trade-off is the breach exposure above. For this platform, document-and-selfie carried the primary identity decision, KBA added a knowledge factor, and the stronger biometric and FIDO2 options remain on the table for higher-assurance steps.
Method
Strength
Trade-off
KBA (EVS out-of-wallet)
No hardware, instant, sometimes required
Answers exposed by data breaches
Document + selfie / biometric liveness
Strong against impersonation
Friction, camera, capture failures
FIDO2 / passkeys
Phishing-resistant for repeat logins
Needs enrollment; not first-time proofing
SMS OTP
Familiar, easy
Weakest; SIM-swap and interception
Frequently asked questions
What is knowledge-based authentication (KBA)?
Knowledge-based authentication verifies identity by asking questions only the real person should be able to answer. Dynamic KBA, also called out-of-wallet questions, generates those questions fresh from public and commercial records each time. That makes it different from static security questions a user picks for themselves, like a pet's name, which are far easier to guess or find online.
What is the difference between static and dynamic KBA?
Static KBA uses questions a user sets, such as a first school or a pet's name, which can be guessed, phished, or found on social media. Dynamic KBA, the kind EVS provides, generates multiple-choice questions from records the person never set and that change every time. It is stronger than static KBA, though still vulnerable to answers exposed in data breaches.
Is KBA required by law?
In specific cases, yes. The IRS requires identity verification, including knowledge-based authentication, when a taxpayer e-signs Forms 8878 or 8879 remotely rather than in person. Many states also require dynamic KBA for remote online notarization. The ESIGN Act and UETA do not mandate KBA, but they accept it as one reasonable way to attribute a signature to a person.
Why can KBA fail after a data breach?
Because the answers - past addresses, loan amounts, vehicles - often sit in breached datasets. The 2017 Equifax breach alone exposed about 147.9 million identities, and security-question dumps such as Yahoo's mean a determined fraudster may already hold the answers. That exposure is why NIST discourages KBA as a standalone authenticator and why roughly 61% of enterprises have reduced or eliminated it since 2021.
KBA vs biometric verification - which is stronger?
Biometric liveness is generally stronger against impersonation because it checks a live face rather than knowledge that can be stolen. KBA's advantage is that it needs no special hardware and no selfie, which makes it useful as a low-friction step-up or second factor. Many flows layer both, using KBA as a lightweight check and biometrics where the stakes are higher.
Can KBA be the only identity check?
No. KBA is best used as a second factor or a step-up check alongside document verification, not as sole proof of identity. NIST SP 800-63 permits knowledge-based verification only as a supplementary check at identity assurance level 2 and does not allow it at level 3, so it should reinforce a stronger check rather than stand alone.
