> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
What is the minimum data a KYC onboarding system must collect for individual customers?
For US banks under CIP (31 CFR § 1020.220), a minimum set is: full legal name, date of birth, address (residential or business), and an identification number (SSN for US citizens; passport or government ID number for non-US persons). Builders must store each field with a collected_at timestamp, the collection channel, and a reference to the verification evidence used. The rule permits documentary and non-documentary verification methods - both outcomes must be logged.
How do I model PEP status in the customer data model?
A PEP status record should contain: the customer ID, the screening date, the data source and version used, the match confidence score, the matched name and role, the analyst disposition (confirmed PEP / false positive / further review), the review timestamp, and the analyst ID. PEP status is not binary - a customer may be a domestic PEP, a foreign PEP, or a PEP associate, each carrying different risk implications. Store the PEP category as an enum with a freetext rationale field. Implement re-screening on a configurable schedule (typically annual) and on adverse media trigger.
What fields should an identity document verification record contain?
At minimum: document type (passport, national ID, driver's licence), issuing country, document number (hashed or encrypted at rest), issue date, expiry date, verification method (automated OCR/liveness, manual review), verification provider name and version, verification outcome (pass / fail / refer), and any failure reason codes. Do not store full document images in the primary database - store them in an encrypted object store (S3 + KMS or equivalent) with a reference key in the verification record.
How should I implement structuring detection in a transaction monitoring system?
Structuring detection requires daily aggregation of cash transactions by customer and business day. The rule logic: for each customer, sum all cash credits and debits on each business day; flag any day where aggregate cash activity approaches the $10,000 CTR threshold (commonly 80–100% of the threshold) without a documented business explanation. Apply a 30-day lookback to catch multi-day structuring patterns - flag customers whose aggregate cash over any rolling 30-day window exceeds the threshold across multiple below-threshold days. Implement as a nightly batch SQL job with configurable alert parameters. (31 U.S.C. § 5324)
What is the SAR filing deadline and how do I track it in software?
US financial institutions must file a SAR with FinCEN within 30 calendar days of detecting suspicious activity that may warrant a SAR. If the suspicious activity involves an identified suspect, the deadline extends to 30 days from detection. Builders must store a detected_at timestamp on every SAR case, compute filing_deadline = detected_at + 30 days, and implement a multi-layered notification system (T-10, T-5, T-2 days). Include a supervisor escalation path for cases approaching the deadline without analyst action. (31 CFR § 1020.320)
How does PSD2 Strong Customer Authentication (SCA) work technically?
PSD2 SCA requires at least two authentication factors from different categories: knowledge (password, PIN), possession (registered device, OTP delivered to a registered number, FIDO2 hardware key), and inherence (fingerprint, facial recognition). The factors must be independent - compromise of one must not undermine the other. Builders implement SCA by combining a server-side session with a second-factor challenge: verify the session (knowledge), then issue a TOTP/FIDO2 challenge (possession or inherence). Dynamic linking requires the SCA code to encode the payment amount and beneficiary IBAN. (PSD2 RTS Art. 4–5, EUR-Lex 2018/389)
What are the technical requirements for a PSD2-compliant Open Banking API?
Open Banking APIs under PSD2 must: use TLS 1.2 minimum; identify the TPP using a PSD2 eIDAS QWAC certificate; implement OAuth2 authorisation code flow with PKCE for consent authorisation; issue scoped access tokens with expiry matching the consent duration; provide revocation endpoints; serve account data endpoints (balances, transactions, account details); and respond to consented requests within the regulatory SLA. Builders implement the token endpoint, authorisation endpoint, and account resource endpoints, validated against the relevant Open Banking API specification (e.g., OBWG UK, Berlin Group NextGenPSD2, or STET).
How should beneficial ownership data be modelled in the database?
Use an entity graph: a legal_entities table (id, name, jurisdiction, LEI, registration_number, entity_type) and a beneficial_ownership junction table (entity_id, owner_person_id OR owner_entity_id, ownership_pct, control_type, verified_at, source_document_ref). The junction supports recursive ownership chains (entity owned by entity owned by natural person). Store verification evidence in a separate bo_verification_evidence table linked by bo_evidence_id. Enforce a CHECK (ownership_pct BETWEEN 0 AND 100) constraint and track the version of the entity structure with structure_as_of timestamps. (31 CFR § 1010.230)
How do I implement a velocity rule in the transaction monitoring system?
A velocity rule has three parameters: metric (transaction count or aggregate amount), window (rolling 24h, 7d, 30d), and threshold. Implementation options: (a) maintain a rolling counter per customer in Redis using sorted sets with score = transaction timestamp, then trim to the window before each check; (b) use a database aggregate query with a time-range filter in a nightly batch. For real-time velocity checks, Redis is preferred for sub-millisecond response. Store rule parameters in a monitoring_rules table so compliance officers can tune thresholds without code releases.
What is the difference between SDD, CDD, and EDD in KYC?
Simplified Due Diligence (SDD) applies to demonstrably low-risk customers (e.g., regulated financial institutions, government bodies) and requires minimal identity verification and infrequent reviews. Standard Customer Due Diligence (CDD) applies to typical customers and requires full identity verification, business purpose understanding, and periodic review. Enhanced Due Diligence (EDD) applies to high-risk customers - PEPs, high-risk jurisdictions, complex ownership structures - and requires senior management approval, additional verification, and more frequent monitoring. Builders implement these as configurable tiers in the onboarding workflow with different form requirements, approval workflows, and monitoring rule sets.
How should I handle OFAC sanctions matches during onboarding?
On a potential sanctions match during onboarding: (a) immediately prevent account opening or transaction processing; (b) log the match with the list date, matched name, SDN entry ID, and match score; (c) route to a compliance analyst for manual review; (d) if the match is confirmed, block the account and file an OFAC report within 10 business days with the relevant field office. Do not alert the customer to the sanctions check or match - tipping-off a sanctioned party is itself a compliance violation. Store the outcome (false positive / confirmed block / declined) with the analyst's name and decision rationale. (31 CFR § 1010.520)
What data should a consent log contain in a PSD2 Open Banking implementation?
A consent log record should contain: consent ID (UUID), customer ID, TPP identifier (from QWAC certificate), TPP name and registration number, consent scopes granted (accounts list, balances, transactions - each as a boolean or scope string), consent creation timestamp, consent expiry timestamp, consent status (active / revoked / expired), revocation timestamp if applicable, the IP address at which consent was granted, and the access token ID(s) issued under this consent. Implement a GET /consents/{consentId} endpoint to allow customers to inspect their active consents. (PSD2 Art. 67, EUR-Lex 2015/2366/EU)
How do I implement a SAR filing workflow?
A SAR workflow should implement these states: alert_raised → analyst_assigned → under_investigation → sar_drafted → pending_supervisor_review → approved / rejected → filed_with_fincen → archived. Each state transition must record the actor (analyst/supervisor), timestamp, and any notes. The SAR XML payload (FinCEN Form 111 format) is generated from the case data at the sar_drafted stage and attached to the case. The filed_with_fincen state stores the BSA E-Filing acknowledgment number. Maintain a tipping_off_flag on the case that prevents the system from notifying the subject of the SAR. (31 CFR § 1020.320)
What is dynamic linking in PSD2 SCA and how do I implement it?
Dynamic linking requires the authentication code produced during SCA to be specific to both the transaction amount and the payee. If either changes after SCA, the code is invalidated. Implementation: when generating the FIDO2 challenge or TOTP seed for a payment, include the payee IBAN and the transaction amount in the challenge data as a signed field. The server verifies that the signed challenge matches the payment details in the submission. For TOTP, include amount and IBAN in the HMAC message alongside the timestamp. (PSD2 RTS Art. 5, EUR-Lex 2018/389)
How long must KYC records be retained?
In the US, CIP records must be retained for five years after account closure (31 CFR § 1020.220). SAR-related records must be retained for five years from the date of filing. EU AMLD requires KYC records to be retained for five years after the customer relationship ends. Builders must implement a retention policy table mapping record type to retention period, storing a retention_expires_at timestamp on each record and blocking deletion before expiry.
How should an AML rules engine be architected to allow compliance officers to tune parameters?
Store all rule parameters (threshold values, window durations, peer group definitions, exception lists) in a database table (aml_rules), not in application code. Each rule record contains: rule ID, rule type, rule name, description, evaluation SQL or expression, parameter JSON, active flag, effective date, and the compliance officer who last modified it. The rules engine loads active rules from the database at startup (or on a configurable refresh interval) and executes them against transaction batches. Compliance officers use an admin UI to modify parameters, which writes new rule versions with full audit trail.