1. LESSON OBJECTIVES (10 TARGETS)

By the end of this lesson, you will be able to:

• Deconstruct the Identity Assurance Levels (IAL) and Authentication Assurance Levels (AAL) defined by NIST SP 800-63.

• Mathematically model biometric false acceptance rates (FAR) and false rejection rates (FRR), and compute the Receiver Operating Characteristic (ROC) curve.

• Design a complete KYC (Know Your Customer) workflow incorporating document verification, liveness detection, and watchlist screening.

• Implement the cryptographic hashing of Personally Identifiable Information (PII) to satisfy GDPR data minimization.

• Analyze AML (Anti-Money Laundering) transaction monitoring using rule-based scoring and graph-based link analysis.

• Quantify the Suspicious Activity Report (SAR) threshold using the Pareto distribution of transaction sizes.

• Explain the FIDO2/WebAuthn protocol for passwordless authentication, including the cryptographic pairing of authenticators.

• Model Decentralized Identity (DID) using the W3C specification, including DID Documents, Verification Methods, and Service Endpoints.

• Distinguish between Verifiable Credentials (VCs) and Zero-Knowledge Proofs (ZKPs) for selective disclosure.

• Simulate a peer-to-peer identity verification flow using the Sovrin/Hyperledger Indy architecture.

2. THE IDENTITY HIERARCHY – IAL, AAL, AND FAL

NIST SP 800-63 establishes three axes for digital identity management.

A. IDENTITY ASSURANCE LEVEL (IAL – HOW MUCH WE TRUST THE IDENTITY CLAIM):

• IAL 1: Self-asserted identity. No proof is required. (e.g., a disposable email sign-up).

• IAL 2: The user must provide physical documentation (e.g., passport, driving license). The document is checked for physical security features (holograms, microprinting, ultraviolet ink) and the photo is matched to the user’s live face.

• IAL 3: The user must appear in person or via a supervised remote video session. A trained agent validates the identity using biometrics and dynamic knowledge-based verification (e.g., asking about past addresses).

B. AUTHENTICATION ASSURANCE LEVEL (AAL – HOW STRONG IS THE LOGIN):

• AAL 1: Single-factor authentication (e.g., password only). Not allowed for financial services.

• AAL 2: Two-factor authentication. Requires possession (e.g., a TOTP token or SMS OTP) and knowledge (password).

• AAL 3: Cryptographic hardware-based authentication. Uses a dedicated hardware security module (HSM) or FIDO2 authenticator. The private key never leaves the device. This is resistant to phishing and MITM attacks.

C. FEDERATION ASSURANCE LEVEL (FAL – TRUST IN FEDERATED IDENTITY PROVIDERS):

• Defines how much a relying party (e.g., the bank) trusts an external identity provider (e.g., Google, National ID system). For financial services, FAL 3 is required, meaning the identity provider must assert the user’s identity using a signed JWT that is cryptographically verified.

3. BIOMETRIC SYSTEMS – THE MATHEMATICS OF MATCHING

Biometrics (fingerprint, iris, facial recognition) are the primary “inherence” factor for SCA. The system operates in two phases: Enrollment and Authentication.

ENROLLMENT PHASE:
The sensor captures the biometric signal. The signal is processed to extract a feature vector (a template). For facial recognition, the feature vector is a 512-dimensional embedding vector generated by a Deep Neural Network (typically using the ArcFace loss function). This vector is normalized to unit length.

AUTHENTICATION PHASE:
The system captures a new biometric sample, extracts a query vector (q), and computes the Euclidean Distance or Cosine Similarity against the stored template vector (t).

• Euclidean Distance: d = sqrt( Σ_{i=1}^n (q_i – t_i)^2 )

• Cosine Similarity: cos(θ) = (q · t) / (||q|| * ||t||)

If d is below a threshold τ (or if cos(θ) is above a threshold), the user is authenticated.

FAR AND FRR (THE FUNDAMENTAL TRADE-OFF):

• False Acceptance Rate (FAR): The probability that an impostor is incorrectly accepted.

  FAR(τ) = ∫_{τ}^{∞} f_impostor(s) ds

• False Rejection Rate (FRR): The probability that a genuine user is incorrectly rejected.

  FRR(τ) = ∫_{-∞}^{τ} f_genuine(s) ds

Where f_impostor and f_genuine are the probability density functions of the matching score for impostors and genuine users, respectively. The threshold τ determines the operating point.

THE ROC CURVE AND DET CURVE:

• The ROC (Receiver Operating Characteristic) curve plots FAR (x-axis) against the True Acceptance Rate (TAR = 1 – FRR) on the y-axis. The area under the ROC curve (AUC) is a single metric of system accuracy. An AUC of 0.99 is considered excellent for financial-grade biometrics.

• The DET (Detection Error Trade-off) curve plots FAR against FRR on a logarithmic scale. The Equal Error Rate (EER) is the point where FAR = FRR. For a typical facial recognition system, EER is around 0.1% to 0.5%.

PRESENTATION ATTACK DETECTION (LIVENESS):
To prevent spoofing (e.g., holding a photo up to the camera), the system uses liveness detection. This can be:

• Active: The user is asked to blink, smile, or turn their head (3D depth mapping using the structured light sensor).

• Passive: The system analyzes texture artifacts, micro-movements, and light reflection using a separate CNN classifier.

4. KYC (KNOW YOUR CUSTOMER) – THE FULL TECHNICAL WORKFLOW

Onboarding a new user for a FinTech application requires a rigorous KYC process. The workflow is as follows:

STEP 1: DATA COLLECTION (FRONT-END):
The user submits:

• Full legal name, Date of Birth, Nationality.

• Residential address.

• Government-issued ID (Passport, Driver’s License, National ID card) – image capture (JPEG/PNG) with high resolution (at least 300 DPI).

• A selfie (for facial matching).

STEP 2: DOCUMENT AUTHENTICATION (BACK-END):
The system uses OCR (Optical Character Recognition) to extract the machine-readable zone (MRZ) from the ID document. The MRZ contains the document number, date of birth, and expiry date. The system validates the Luhn algorithm (or a more complex checksum for passport numbers) to verify that the MRZ is internally consistent. For passports, the checksum is computed as:

Checksum = (sum of digits with alternating weights) mod 10

The system also extracts the photo from the ID and compares it to the selfie using a facial matching engine (we extract a 512-dim embedding and compute the cosine similarity). If the similarity score is above 0.75, the system proceeds.

STEP 3: DATABASE SCREENING (PEP AND SANCTIONS):
The extracted name and date of birth are hashed (using SHA-256) and queried against third-party watchlists (e.g., OFAC SDN list, INTERPOL, and Politically Exposed Persons – PEP databases). The hash is used to avoid transmitting plaintext PII over the network. The screening result is a Boolean flag: is_hit (True/False). If is_hit is True, the onboarding is escalated to a manual compliance review.

STEP 4: ADDRESS VERIFICATION:
The user may be required to upload a utility bill (electricity, water, gas) issued within the last 3 months. The system OCRs the bill to extract the address. The system also uses geocoding to verify that the address is a real physical location (not a P.O. Box). If the address is validated, the system stores it.

STEP 5: RISK SCORING AND ONBOARDING DECISION:
The system computes a risk score (0 to 100) using a decision tree model. Factors include: country of residence (high-risk jurisdictions get +20 points), document type, age, and source of funds. If the score is < 30, the user is automatically approved (fast-track). If 30-70, the user is manually reviewed. If > 70, the user is rejected.

PII HASHING AND DATA MINIMIZATION:
Under GDPR, the bank must not store raw PII for longer than necessary. The database stores:

• national_id_hash = SHA256(National_ID + Salt). The salt is per-user and stored separately in a Hardware Security Module (HSM).

• date_of_birth_hash = SHA256(DOB + Salt).
  This means that even if the database is breached, the attacker cannot recover the original PII without the salt.

5. AML (ANTI-MONEY LAUNDERING) – TRANSACTION MONITORING

AML systems are designed to detect suspicious patterns. Two primary approaches are used: Rule-based scoring and Graph-based link analysis.

A. RULE-BASED DETECTION:
Compliance teams define rules such as:

• Cash transaction > €10,000 in a single day.

• Rapid in-and-out transfers (deposit and withdrawal within 24 hours) – also known as “structuring” or “smurfing.”

• Transactions to known high-risk jurisdictions (e.g., countries on the FATF grey list).

Each rule assigns a score (S_i). The total risk score for a customer is:

R_total = Σ_{i=1}^m w_i * S_i

Where w_i are weights determined by the compliance department. If R_total exceeds a threshold T (e.g., 80), the transaction is flagged and a SAR (Suspicious Activity Report) is generated. The threshold T is dynamically adjusted using the Extreme Value Theory to ensure that the false positive rate is below 0.1%.

B. GRAPH-BASED LINK ANALYSIS (NETWORK THEORY IN AML):
Money launderers use layers of accounts to obscure the source. The banking network is represented as a directed graph G(V, E), where V are accounts and E are transactions with a timestamp and amount. Suspicious patterns are “cycles” (circular flows) and “stars” (one account sending to many, or many sending to one).

Algorithm:

• The PageRank algorithm is applied to the transaction graph to identify accounts with high influence.

• The Community Detection algorithm (e.g., Louvain method) identifies groups of tightly interconnected accounts. If a group has no real economic relationship (all individuals are unrelated), it is flagged.

• The Temporal Degree Centrality measures the volume of transactions flowing through an account over a sliding window of 7 days. If an account’s centrality suddenly spikes by 10 standard deviations, an alert is generated.

C. BEHAVIORAL PROFILING (ANOMALY DETECTION):
The system builds a baseline profile for each customer using historical data. For each transaction, the system computes the Mahalanobis Distance to the baseline:

D_M = sqrt( (x – μ)^T * Σ^{-1} * (x – μ) )

Where x is the feature vector of the new transaction (amount, merchant, geolocation, device ID), μ is the mean vector of the baseline, and Σ is the covariance matrix. If D_M > 3 (i.e., more than 3 standard deviations from the mean), the transaction is anomalous and placed under review.

6. FIDO2 AND WEBAUTHN – PASSWORDLESS AUTHENTICATION

FIDO2 is the most secure authentication standard for financial applications. It eliminates the password (which is vulnerable to phishing and credential stuffing).

THE CRYPTOGRAPHIC PRINCIPLE:
During registration, the user’s device (a smartphone or hardware key) generates a new asymmetric key pair:

• Private Key (sk): Stored securely in the device’s TEE (Trusted Execution Environment) or Secure Enclave. It never leaves the device.

• Public Key (pk): Sent to the bank’s server. The server stores the public key associated with the user’s account.

AUTHENTICATION FLOW (THE CHALLENGE-RESPONSE PROTOCOL):

1. The user attempts to log in. The bank sends a random challenge (C) – a 32-byte cryptographically secure random number.

2. The user’s device signs the challenge with its private key:

   Signature = ECDSA_Sign(sk, C || RelyingParty_ID || User_Presence_Flag)

3. The user must physically interact with the device (e.g., tap the fingerprint sensor or press a button) to set the User_Presence_Flag to 1. This prevents remote malware from using the device without the user’s knowledge.

4. The device sends the signature back to the bank.

5. The bank verifies the signature using the stored public key:

   ECDSA_Verify(pk, C || RelyingParty_ID || User_Presence_Flag, Signature)
   If verification passes, the user is authenticated. This is completely immune to man-in-the-middle attacks because the challenge is unique per session and the RelyingParty_ID is bound to the domain.

STATISTICAL SECURITY LEVEL:
FIDO2 uses the P-256 elliptic curve, which provides 128 bits of security. The probability of guessing the private key is 2^(-256), which is astronomically small (less than the probability of a cosmic ray flipping a bit in the server’s RAM).

7. DECENTRALIZED IDENTITY (DID) – THE W3C SPECIFICATION

Decentralized Identity shifts control from centralized identity providers (like Google or Facebook) to the user. The user holds a DID (Decentralized Identifier), which is a globally unique identifier (e.g., did:ethr:0x123... or did:sov:1234...).

THE DID DOCUMENT (CRYPTOGRAPHIC ANCHOR):
The DID resolves to a DID Document, which is a JSON-LD object containing:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [
    {
      "id": "did:example:123456789abcdefghi#keys-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyMultibase": "zF3g1..."
    }
  ],
  "authentication": ["did:example:123456789abcdefghi#keys-1"],
  "service": [
    {
      "id": "did:example:123456789abcdefghi#bank-service",
      "type": "BankAccountService",
      "serviceEndpoint": "https://bank.com/api/accounts"
    }
  ]
}

VERIFIABLE CREDENTIALS (VCS):
A bank can issue a VC to the user stating “Account #123 is in Good Standing.” The VC is signed by the bank’s DID (using its private key). The user stores this VC in their digital wallet. When the user wants to prove their creditworthiness to a lender, they present the VC. The lender verifies the bank’s signature on the VC by resolving the bank’s DID and checking the public key.

ZERO-KNOWLEDGE PROOFS (ZKPS) FOR SELECTIVE DISCLOSURE:
Instead of revealing the entire VC (which might contain sensitive data like the exact account balance), the user can present a Zero-Knowledge Proof that only reveals the assertion they want to prove. For example, the user can prove “My account balance is > $10,000” without revealing the actual number. This is mathematically achieved using zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge). The prover (user) generates a proof π such that:

Verifier(π, Public_Statement) = True, and the prover does not reveal the private witness (the exact balance).

The computational cost of generating a zk-SNARK is high (roughly 10^9 operations), but recent advancements in Groth16 have reduced it to ~3 seconds on a modern smartphone.

8. THE SOVRIN / HYPERLEDGER INDY ARCHITECTURE

This is the most deployed enterprise framework for decentralized identity.

THE LEDGER STRUCTURE:
The ledger is a permissioned blockchain (RBF – Replicated Byzantine Fault Tolerance). It does not store personal data. It only stores:

• NYM transactions: mapping a DID to a public key.

• ATTRIB transactions: mapping a DID to an attribute tag (e.g., “has_passed_kyc” = True).

• SCHEMA and CRED_DEF transactions: defining the structure of VCs.

THE HOLDER-PROVER-VERIFIER FLOW:

1. Issuer (Bank): Defines a credential schema (e.g., “KYC_Credential” with fields: name, DOB, address, account_status). The issuer creates a Credential Definition (CredDef) containing the public keys for signing the credential.

2. User (Holder): Requests the credential. The issuer generates a credential signature (using the BLS signature scheme, which is aggregation-friendly) and sends it to the user. The user stores it in their wallet.

3. User (Prover): Wants to open a new account at a different bank. The user presents the credential.

4. Verifier (New Bank): The verifier checks the issuer’s public key against the ledger (to ensure the issuer is trusted and hasn’t been revoked). The verifier validates the user’s signature over the credential. If all checks pass, the user is onboarded.

REVOCATION MECHANISM:
The issuer can revoke a credential (e.g., if the user’s account is closed). The issuer publishes a revocation registry on the ledger. The registry uses an Accumulator (a cryptographic data structure) that allows the prover to prove non-revocation without revealing the accumulator’s internal state. The accumulator uses RSA-based or bilinear pairing accumulators. The proof of non-revocation is O(1) in size.

9. GDPR AND THE RIGHT TO BE FORGOTTEN (DATA SOVEREIGNTY)

FinTechs operating in the EU must comply with GDPR Article 17 – the Right to Erasure.

TECHNICAL IMPLEMENTATION OF DATA DELETION:

• Soft Delete: The database marks the user record as deleted = True with a deleted_timestamp. The record remains for audit trail purposes (regulatory requirement to retain transaction history for 7-10 years).

• Hard Delete (Pseudonymization): For PII fields that are not required for audit, the system overwrites them with a NULL or a cryptographic hash of a dummy value. The system uses a Tokenization Service – the PII is mapped to a token. The token is stored in the database, while the actual PII is stored in a separate, encrypted vault. When a user requests deletion, the vault entry is destroyed, rendering the tokens meaningless.

• Anonymization for Analytics: If the bank wants to keep the data for business intelligence, it must apply Differential Privacy. Differential privacy adds calibrated noise (from a Laplace or Gaussian distribution) to query results. The privacy budget (ε) quantifies the maximum information leakage. For a query function f(D), the algorithm adds noise:

M(D) = f(D) + Laplace( Δf / ε )
Where Δf is the sensitivity of the query (the maximum change in the output caused by adding or removing one user’s data). With ε = 1, the bank can guarantee that an attacker cannot determine with high probability whether a specific user is in the dataset.

10. FRAUD DETECTION – BEHAVIORAL BIOMETRICS AND DEVICE FINGERPRINTING

Beyond document verification, the system continuously monitors user behavior during a session.

A. TYPING DYNAMICS (KEYSTROKE BIOMETRICS):
The system measures the dwell time (how long a key is pressed) and the flight time (interval between releasing one key and pressing the next). Each user has a unique rhythm. The system extracts a feature vector and computes the Mahalanobis distance to the enrolled template. If the distance exceeds a threshold (e.g., 2.5), the session is flagged for step-up authentication.

B. MOUSE MOVEMENT AND TOUCH PRESSURE (FOR MOBILE):
On mobile devices, the system records the accelerometer and gyroscope data (via JavaScript). It uses a Long Short-Term Memory (LSTM) neural network to classify whether the movements are human (natural) or robotic (scripted). The LSTM processes a time series of 100 samples and outputs a probability of is_human. If is_human < 0.8, the transaction is blocked.

C. DEVICE FINGERPRINTING:
The system collects over 100 attributes of the user’s browser/device: user-agent, screen resolution, installed fonts, WebGL renderer, canvas fingerprint (a hash of the rendering of a hidden canvas element), and timezone offset. The device fingerprint is hashed to a 64-bit integer. The system maintains a blacklist of fingerprints known to be associated with fraud rings. If a fingerprint appears on the blacklist, the account is put under manual review.