> Avviso: Questo contenuto è destinato esclusivamente a scopi educativi e di riferimento per i software builder. Non costituisce consulenza medica, legale, finanziaria o regolamentare. Consultare un professionista qualificato prima di prendere decisioni basate su questo contenuto.
Quali sono i dati minimi che un sistema di onboarding KYC deve raccogliere per i clienti persone fisiche?
Per le banche USA ai sensi del CIP (31 CFR § 1020.220), il set minimo è: nome legale completo, data di nascita, indirizzo (residenziale o aziendale) e un numero identificativo (SSN per i cittadini USA; numero di passaporto o documento governativo per i non-US). I builder devono archiviare ogni campo con un timestamp collected_at, il canale di raccolta e un riferimento alla prova di verifica utilizzata. La regola consente metodi di verifica documentale e non documentale - entrambi i risultati devono essere registrati.
Come si modella lo status PEP nel modello dati del cliente?
Un record di status PEP deve contenere: l'ID cliente, la data di screening, la fonte dei dati e la versione utilizzata, il punteggio di confidence della corrispondenza, il nome e il ruolo corrispondenti, la disposizione dell'analista (PEP confermato / falso positivo / ulteriore revisione), il timestamp della revisione e l'ID dell'analista. Lo status PEP non è binario - un cliente può essere un PEP domestico, un PEP straniero o un associato PEP, ognuno con implicazioni di rischio diverse. Archiviare la categoria PEP come enum con un campo freetext per la motivazione. Implementare la riesaminazione su una pianificazione configurabile (tipicamente annuale) e su trigger di media avversi.
Quali campi deve contenere un record di verifica documentale dell'identità?
Come minimo: tipo di documento (passaporto, documento d'identità nazionale, patente di guida), paese emittente, numero di documento (hashed o crittografato a riposo), data di emissione, data di scadenza, metodo di verifica (OCR/liveness automatico, revisione manuale), nome e versione del provider di verifica, esito della verifica (pass / fail / refer) e gli eventuali codici di failure reason. Non archiviare le immagini complete dei documenti nel database primario - archiviarle in un object store crittografato (S3 + KMS o equivalente) con una chiave di riferimento nel record di verifica.
Come si implementa la detection della strutturazione in un sistema di transaction monitoring?
La detection della strutturazione richiede l'aggregazione giornaliera delle transazioni in contante per cliente e giorno lavorativo. La logica della regola: per ogni cliente, sommare tutti i crediti e debiti in contante in ogni giorno lavorativo; segnalare qualsiasi giorno in cui l'attività in contante aggregata si avvicini alla soglia CTR di $10.000 (comunemente 80–100% della soglia) senza una documentata spiegazione commerciale. Applicare una finestra di lookback di 30 giorni per rilevare pattern di strutturazione multi-giorno - segnalare i clienti il cui contante aggregato in qualsiasi finestra mobile di 30 giorni supera la soglia su più giorni al di sotto della soglia. Implementare come processo batch SQL notturno con parametri di alert configurabili. (31 U.S.C. § 5324)
Qual è la scadenza per la presentazione del SAR e come si tiene traccia in software?
Gli istituti finanziari USA devono presentare un SAR al FinCEN entro 30 giorni di calendario dal rilevamento di un'attività sospetta che può giustificare un SAR. Se l'attività sospetta coinvolge un sospettato identificato, la scadenza si estende a 30 giorni dal rilevamento. I builder devono archiviare un timestamp detected_at su ogni caso SAR, calcolare filing_deadline = detected_at + 30 giorni e implementare un sistema di notifica a più livelli (T-10, T-5, T-2 giorni). Includere un percorso di escalation supervisore per i casi in avvicinamento alla scadenza senza azioni dell'analista. (31 CFR § 1020.320)
Come funziona tecnicamente la Strong Customer Authentication (SCA) PSD2?
La SCA PSD2 richiede almeno due fattori di autenticazione di categorie diverse: conoscenza (password, PIN), possesso (dispositivo registrato, OTP consegnato a un numero registrato, chiave hardware FIDO2) e inerenza (impronta digitale, riconoscimento facciale). I fattori devono essere indipendenti - la compromissione di uno non deve indebolire l'altro. I builder implementano la SCA combinando una sessione lato server con una challenge di secondo fattore: verifica la sessione (conoscenza), poi emette una challenge TOTP/FIDO2 (possesso o inerenza). Il collegamento dinamico richiede che il codice SCA codifichi l'importo del pagamento e l'IBAN del beneficiario. (RTS PSD2 Art. 4–5, EUR-Lex 2018/389)
Quali sono i requisiti tecnici per un'API Open Banking conforme alla PSD2?
Le API Open Banking ai sensi della PSD2 devono: utilizzare TLS 1.2 come minimo; identificare il TPP tramite certificato eIDAS QWAC PSD2; implementare il flusso di autorizzazione OAuth2 authorization code con PKCE per l'autorizzazione del consenso; emettere access token scoped con scadenza corrispondente alla durata del consenso; fornire endpoint di revoca; servire gli endpoint delle risorse account (saldi, transazioni, dettagli del conto); e rispondere alle richieste consentite entro lo SLA normativo. I builder implementano l'endpoint token, l'endpoint di autorizzazione e gli endpoint delle risorse account, validati rispetto alla specifica API Open Banking rilevante (es. OBWG UK, Berlin Group NextGenPSD2 o STET).
Come si modella la titolarità effettiva nel database?
Usare un grafo di entità: una tabella legal_entities (id, nome, giurisdizione, LEI, registration_number, entity_type) e una tabella di giunzione beneficial_ownership (entity_id, owner_person_id O owner_entity_id, ownership_pct, control_type, verified_at, source_document_ref). La giunzione supporta catene di proprietà recursive (entità posseduta da entità posseduta da persona fisica). Archiviare le prove di verifica in una tabella separata bo_verification_evidence collegata tramite bo_evidence_id. Applicare un vincolo CHECK (ownership_pct BETWEEN 0 AND 100) e tracciare la versione della struttura dell'entità con timestamp structure_as_of. (31 CFR § 1010.230)
Come si implementa una velocity rule nel sistema di transaction monitoring?
Una velocity rule ha tre parametri: metrica (numero di transazioni o importo aggregato), finestra (rolling 24h, 7g, 30g) e soglia. Opzioni di implementazione: (a) mantenere un contatore rolling per cliente in Redis utilizzando sorted set con score = timestamp della transazione, poi trimmare alla finestra prima di ogni controllo; (b) usare una query di aggregazione del database con un filtro time-range in un batch notturno. Per i controlli di velocity in tempo reale, Redis è preferibile per la risposta sub-millisecondo. Archiviare i parametri delle regole in una tabella monitoring_rules in modo che i compliance officer possano regolare le soglie senza rilasci di codice.
Qual è la differenza tra SDD, CDD ed EDD nel KYC?
L'Adeguata Verifica Semplificata (SDD) si applica ai clienti a rischio dimostrabilmente basso (es. istituti finanziari regolamentati, enti governativi) e richiede una verifica dell'identità minimale e revisioni poco frequenti. La Customer Due Diligence standard (CDD) si applica ai clienti tipici e richiede la verifica completa dell'identità, la comprensione dello scopo commerciale e la revisione periodica. L'Enhanced Due Diligence (EDD) si applica ai clienti ad alto rischio - PEP, giurisdizioni ad alto rischio, strutture di proprietà complesse - e richiede l'approvazione dell'alta direzione, una verifica aggiuntiva e un monitoraggio più frequente. I builder implementano questi livelli come tier configurabili nel workflow di onboarding con diversi requisiti di form, workflow di approvazione e set di regole di monitoraggio.
Come si gestisce una corrispondenza nelle sanzioni OFAC durante l'onboarding?
In caso di potenziale corrispondenza nelle sanzioni durante l'onboarding: (a) impedire immediatamente l'apertura del conto o l'elaborazione della transazione; (b) registrare la corrispondenza con la data della lista, il nome corrispondente, l'ID dell'entità SDN e il punteggio di corrispondenza; (c) instradare a un analista di compliance per la revisione manuale; (d) se la corrispondenza è confermata, bloccare il conto e presentare un report OFAC entro 10 giorni lavorativi. Non avvisare il cliente del controllo o della corrispondenza nelle sanzioni - avvisare una parte sanzionata è di per sé una violazione della compliance. Archiviare l'esito (falso positivo / blocco confermato / rifiutato) con il nome dell'analista e la motivazione della decisione. (31 CFR § 1010.520)
Quali dati deve contenere un registro del consenso in un'implementazione PSD2 Open Banking?
Un record del registro del consenso deve contenere: ID consenso (UUID), ID cliente, identificatore TPP (dal certificato QWAC), nome e numero di registrazione del TPP, scope del consenso concessi (lista conti, saldi, transazioni - ciascuno come booleano o stringa di scope), timestamp di creazione del consenso, timestamp di scadenza del consenso, stato del consenso (attivo / revocato / scaduto), timestamp di revoca se applicabile, l'indirizzo IP da cui è stato concesso il consenso, e l'ID/gli ID dell'access token emessi con questo consenso. Implementare un endpoint GET /consents/{consentId} per consentire ai clienti di esaminare i propri consensi attivi. (PSD2 Art. 67, EUR-Lex 2015/2366/EU)
Come si implementa un workflow di presentazione SAR?
Un workflow SAR deve implementare questi stati: alert_raised → analyst_assigned → under_investigation → sar_drafted → pending_supervisor_review → approved / rejected → filed_with_fincen → archived. Ogni transizione di stato deve registrare l'attore (analista/supervisore), il timestamp e le eventuali note. Il payload XML SAR (formato FinCEN Form 111) viene generato dai dati del caso nella fase sar_drafted e allegato al caso. Lo stato filed_with_fincen archivia il numero di riconoscimento BSA E-Filing. Mantenere un flag tipping_off_flag sul caso che impedisce al sistema di notificare al soggetto del SAR il suo status. (31 CFR § 1020.320)
Per quanto tempo devono essere conservati i record KYC?
Negli USA, i record CIP devono essere conservati per cinque anni dopo la chiusura del conto (31 CFR § 1020.220). I record correlati ai SAR devono essere conservati per cinque anni dalla data di presentazione. La AMLD UE richiede la conservazione dei record KYC per cinque anni dopo la fine del rapporto con il cliente. I builder devono implementare una tabella delle policy di conservazione che mappa il tipo di record al periodo di conservazione, archiviando un timestamp retention_expires_at su ogni record e bloccando la cancellazione prima della scadenza.
Come si implementa il dynamic linking nella SCA PSD2?
Il dynamic linking richiede che il codice di autenticazione prodotto durante la SCA sia specifico sia per l'importo della transazione che per il beneficiario. Se uno dei due cambia dopo la SCA, il codice viene invalidato. Implementazione: quando si genera la challenge FIDO2 o il seed TOTP per un pagamento, includere l'IBAN del beneficiario e l'importo della transazione nei dati della challenge come campo firmato. Il server verifica che la challenge firmata restituita corrisponda ai dettagli del pagamento nella submission. Per TOTP, includere importo e IBAN nel messaggio HMAC insieme al timestamp. (RTS PSD2 Art. 5, EUR-Lex 2018/389)
Come si architetta un motore di regole AML per consentire ai compliance officer di regolare i parametri?
Archiviare tutti i parametri delle regole (valori soglia, durate delle finestre, definizioni dei peer group, liste di eccezioni) in una tabella del database (aml_rules), non nel codice dell'applicazione. Ogni record di regola contiene: ID regola, tipo di regola, nome della regola, descrizione, SQL o espressione di valutazione, JSON dei parametri, flag attivo, data di efficacia e il compliance officer che l'ha modificata l'ultima volta. Il motore di regole carica le regole attive dal database all'avvio (o a un intervallo di refresh configurabile) e le esegue sui batch di transazioni. I compliance officer utilizzano un'interfaccia admin UI per modificare i parametri, che scrive nuove versioni della regola con audit trail completo.