KYC/AML ინტეგრაცია გადამოწმების პროვაიდერთან

1) რატომ არის ეს აუცილებელი და რომელი KPI მნიშვნელოვანია

მიზნები: რეგულატორების მოთხოვნების დაცვა, თაღლითობის/გათეთრების პრევენცია, ჩარდბეკების შემცირება და პარტნიორების/გადახდების რისკები მინიმალური ხახუნის პირობებში.

ძირითადი მეტრიკა:

Approval rate (ბაზრის სეგმენტების/გადახდების/VIP), FPR/FNR, ონბორდის დრო (p95), მოთამაშისთვის გადამოწმების ღირებულება.
სანქციების Hit-rate/PEP/Adverse Media, სახელმძღვანელო საქმეების წილი, არასრული შემოწმების პროცენტი.
SLA პროვაიდერი (აფთიაქი, ლატენცია, p95 პასუხი), რეაგირება/ინტეგრაციის შეცდომები.

2) ინტეგრაციის ძირითადი არქიტექტურა

ფენები:

1. Orchestrator (თქვენი risk-onboarding სერვისი): პროვაიდერებს შორის მოთხოვნების გადახედვა წესების/ქვეყნის/აუდიტის ტიპების შესაბამისად.

2. Providers SDK/API: KYC (ID + Liveness), AML (санкции/PEP/Adverse Media), Address, Age, Device.

3. Feature Store/Risk Engine: ინახავს შედეგებს, დროშებს, ფიჩქებს სკორინგისა და ანტიფროდისთვის.

4. Case მენეჯმენტი: სახელმძღვანელო შემოწმება, გასაჩივრება, მეორე რიგის მიმოხილვა.

5. Audit & Compliance: გადაწყვეტილებების უცვლელი ლოგოები, წესების/მოდელების ვერსია, რეგულატორის მოხსენებები.

მოვლენების ნაკადები:

რეგისტაცია Age/ID (მინიმალური KYC იურისდიქციით).
First Deposit/Withdrawal - Enhanced Due Diligence (EDD ოდენობით/რისკებში).
Recurring AML Screening: სანქციების გადატვირთვა/REP გრაფიკის მიხედვით (ყოველდღიურად/ყოველკვირეულად).
Trigger-based: დეტალების/მოწყობილობის/geo-re-screen შეცვლა.

3) შემოწმების ტიპები და რას აკეთებენ ისინი

დოკუმენტების გადაცემა: პასპორტი/ID/წყლები. სერთიფიკატი/ბინადრობის ნებართვა; OCR + MRZ/Barcode, ავთენტურობის ჩეკი.

Liveness & Biometrics: აქტიური/პასიური ცხოვრება, face-match (selfie-document).

Address Verification: address (address bill/საბანკო ამონაწერი), ზოგჯერ მისამართების რეესტრები.

Sanctions/PEP/Watchlists: OFAC/UN/EU/UK HMT + ადგილობრივი; პოლიტიკურად მნიშვნელოვანი პირები; არასასურველი მედიის/სასამართლო ქრონიკების სიები (Adverse Media).

Age Verification: დაბადების თარიღი ადგილობრივი ბარიერები.

Device/Email/Phone: რისკის სიგნალები (ერთჯერადი დომენები, ვირტუალური ნომრები, მარიონეტული/ჰოსტინგი).

KYB (პარტნიორებისთვის/მეწარმეებისთვის): ნორმატიული დოკუმენტები, ბენეფიციარები (UBO), სარეგისტრაციო რეესტრები, უარყოფითი ამბები.

4) ორკესტრი და რისკზე დაფუძნებული მიდგომა

მარშრუტიზაციის წესები: დოკუმენტის ქვეყანა - პროვაიდერი A, თუ არ არსებობს საფარი - პროვაიდერი B; VIP/მაღალი თანხა EDD პაკეტი.

step-up ლოგიკა: რბილი ჩეკი (მონაცემთა წყაროები), რისკის ქვეშ, ჩვენ ვითხოვთ სელფს/დოკუმენტებს.

კომპოზიცია: AML ეკრანის + IDV + Address კომბინაცია დამოკიდებულია იურისდიქციაზე (MGA/UKGC/Curacao და სხვ.) და სასიცოცხლო ციკლის ეტაპზე (onboarding vs payout).

Re-screening: პერიოდული (მაგალითად, ყოველდღე სანქციებით) და ღონისძიება (ქვეყნის/დოკუმენტის ცვლილება).

5) API- ის დიზაინი და ინტეგრაციის ნიმუშები

Idempotence & retries: ყველა გამოწვევა - იდემპოტენტურობის გასაღებით; ექსპონენციალური რეტრატორები, ტაიმაუტები, ცირკუიტ-ბრეიკერი.

ვებჰუკი: ასინქრონული სტატუსები.

შეყვანის შესაბამისობა: ფორმატის კონტროლი (MRZ, ISO ქვეყანა, ტაიპის დოკუმენტი).

არტეფაქტების შენახვა: დაშიფვრა, TTL/retention იურისდიქციებზე, დაშვება „მინიმალური აუცილებელი“ პრინციპით.

მოთხოვნის მაგალითი (ფსევდო):

http
POST /kyc/start
{
"user_id": "u_123",  "flows": ["IDV","AML"],  "country_hint": "DE",  "document_types": ["PASSPORT","NATIONAL_ID"],  "webhook_url": "https://risk. example. com/webhooks/kyc"
}

პროვაიდერის პასუხი:

json
{
"session_id": "sess_abc",  "status": "pending",  "redirect_url": "https://provider/flow/sess_abc"
}

ვებჰუკის შედეგი:

json
{
"session_id": "sess_abc",  "status": "approved",  "checks": {
"idv": {"liveness": "pass", "face_match": 0. 92, "doc_authenticity": "pass"},   "aml": {"sanctions": "clear", "pep": "clear", "adverse_media": "none"}
},  "risk_score": 18
}

6) მონაცემთა ხარისხი: ტიპიური პრობლემები და გადაწყვეტილებები

სახელების ტრანსლიტერაცია/ცვალებადობა: გამოიყენეთ ფონური ალგორითმები, ნორმალიზაცია, ალიას ცხრილი.

არა ლათინური სკრიპტები: კირიული/არაბული ენების/ჰანზის სახელების შედარება - ადგილობრივი შედარების მოდულები.

დაბადების თარიღი/მისამართი: ფორმატირება, ჯვარედინი შემოწმება დოკუმენტით და გადახდის მისამართით (BIN/AVS).

ყალბი დამთხვევები სანქციებში/REP: fuzzy-score- ის კონფიგურაცია და ესკალაციის წესები (ახალგაზრდა სახელები, ხშირი გვარები).

ფოტო ხარისხი: UX მინიშნებები (შუქი, ჩარჩო, ბლიკი), ავტომატური სიმძიმის/კუთხის კონტროლი.

7) SLA, დაკვირვება და ალერტები

Latency მიზანი: ინტერაქტიული ონბორდი 60-120 ms კატალოგის/სკრინინგის + ასინქრონული ნაბიჯების მოთხოვნით 2-3 წუთი (დოკუმენტები).

აფთიაქი: 99. 9% კრიტიკულ ენდოინტებზე; ორმაგი პროვაიდერი (აქტიური/აქტიური-სტანდარტი).

ალერტები: ზრდა 'error _ rate', დეგრადაცია 'hit _ rate', ნახტომი 'მიმოხილვა _ მიმოხილვა ", ვებჰუკების" მშვიდი ფანჯრები ", OCR/Liveness შეფერხებები.

Logs/trace: correlation-ID წინა პროვაიდერიდან; masked payloads; გადაწყვეტილების შენახვა და მიზეზები.

8) შემთხვევების მენეჯმენტი

შემთხვევების ხაზი: პრიორიტეტი ოდენობით/რისკით/რეგიონში.

ფლეიბუკი: რა უნდა მოითხოვოს კლიენტისგან (სელფი, კიდევ ერთი დოკუმენტი, address proof).

SLA სახელმძღვანელო საქმეებში: p95-24 საათი; high-value ≤ 2 ч.

გასაჩივრება: მეორე მატჩი + დამოუკიდებელი მიმოხილვა; უარის თქმის მიზეზების დოკუმენტაცია.

9) შესაბამისობა და კონფიდენციალურობა

GDPR/ადგილობრივი ანალოგები: purpose limitation, dation minimization, წვდომის/მოცილების უფლება (სადაც გამოიყენება).

PCI DSS: თუ გადახდის მონაცემები გავლენას ახდენს.

PSD2/SCA: კორელაცია გადახდის ნაბიჯებზე ძლიერი ავთენტიფიკაციით.

Retention: შეინახეთ მხოლოდ საჭირო ნივთები და მხოლოდ ის, რაც მოითხოვს კანონს/რეგულატორს.

Expainability: ჩაწერეთ „decision rationale“ - რაზე იყო დაფუძნებული სისტემა (liveness fail, doc mismatch, PEP hit).

10) შესყიდვის ღირებულება და მოდელი

Pricing: per-check, პაკეტის ტარიფები, რეგიონალური კოეფიციენტები, გადახდები EDD/Adverse Media- სთვის.

ოპტიმიზაცია: რისკის დაფუძნებული ორკესტრი (იაფი პროვაიდერი - ძვირი ფოლბეკზე), შედეგების ქვა TTL- ზე, დელტაში re-screen.

RFP შემოწმების სია: დოკუმენტების/ქვეყნების საფარი, სიზუსტე/ფაქტობრივი მატჩის სიზუსტე, სანქციების განახლების სიხშირე/REP, latence, ვებჰუკი, SDK, მოხსენებები, DPIA/სერთიფიკატი, წინასწარი ვარიანტები, სასამართლო/მარეგულირებელი პრაქტიკა, iGaming- ის რეფერენდები.

11) KYB: როდესაც მუშაობთ B2V/პარტნიორებთან

რეგისტრატორები: კომპანიების სახლი, ადგილობრივი სავაჭრო რეესტრები, UBO ჯაჭვები.

დოკუმენტები: ინკორპორაცია, წესდება, საბანკო წერილები, დირექტორები/მინდობილობა.

სკრინინგი: სანქციები/REP UBO და დირექტორებისთვის, Adverse Media ბრენდის/იურიდიული პირისთვის.

გამომწვევი მიზეზები: დირექტორის/მისამართის/ბენეფიციარის შეცვლა, ბრუნვის მკვეთრი ზრდა.

12) UX და კონვერტაცია: როგორ არ „დაარღვიოთ“ ონბორდი

მობილური პირველი: SDK ავტო მოთხრობებით (ჩარჩო, ფერდობზე, ბლიკის დაცვა).

ჰაიდი მომხმარებლისთვის: რა უნდა გააკეთოთ წინასწარ (დოკუმენტი, განათება), რამდენ დროს დასჭირდება პროცესი.

პროგრესი ბარი და მკაფიო სტატუსები.

Graceful fallback: თუ კამერა/სენსორები არ არის ხელმისაწვდომი - ალტერნატიული ნაკადი (მანიპულირება + შემდგომი გადამოწმება).

13) ინციდენტები და ხალხური

Fail-safe რეჟიმი: პროვაიდერის დაცემისას - რეზერვზე გადასვლა + მინიმალური საკმარისი წესების გამოყენება.

Degradation policy: ჩვენ ვუშვებთ მხოლოდ მცირე ლიმიტის ანაბრებს აუდიტის დასრულებამდე.

გადავადებული გადამოწმება: დროებითი ლიმიტების გაცემა, სადაც აღინიშნა ნდობის აუცილებლობის შესახებ.

14) ინტეგრაციის ტესტირება და სერტიფიკაცია

პროვაიდერების ქვიშაქვები: „ბედნიერი „/„ უბედური “გზების სკრიპტები, edge შემთხვევები (ბლიკები, მოჭრილი დოკუმენტი, ტყუპები).

კონტრაქტის ტესტები: პასუხის სქემის დაფიქსირება, API ვერსიების მიგრაცია.

დატვირთვა: გამოშვების პიკი/პრომო (x5-x10 ტრაფიკი), გრძელი ვებჰუკი, მოვლენების რეპორტიორი.

DR- სავარჯიშოები: ერთი პროვაიდერის გამორთვა, ვებჰუკების ვარდნა, rollback ვერსია.

15) ტიპიური გადაწყვეტილებების მიღების წესები

decision-table- ის მაგალითი (გამარტივებული):

პირობა	მოქმედება	კომენტარი
Sanctions=hit (strong match)	DENY	ესკალაცია შესაბამისობაში, მოხსენება
PEP=possible + Adverse=negative	REVIEW/EDD	დოპი სახსრების წყაროები
Liveness=fail или FaceMatch<0. 8	RETRY (1-2 ჯერ) REVIEW	UX რჩევები
Address=fail + High-risk country	HOLD	Address Proof კვლავ
Clean KYC/AML + Low risk score	APPROVE	პოლიტიკის შეზღუდვები

16) სრული შემთხვევის მაგალითი (შემოკლებით)

სცენარი: ახალი მოთამაშე გერმანიიდან, ანაბარი 300 ევრო, ბონუსის მოთხოვნა.

1. Soft check (AML fast): clear.

2. IDV: პასპორტი + selfie, liveness = pass, face _ match = 0. 93, doc=authentic.

3. Address: utility bill დასრულდა.

4. Decision: APROVE, გამომავალი ლიმიტი 2,000 ევრომდე, განმეორებითი AML-re-screen ყოველდღიურად.

5. აუდიტი: ჩაწერილია ძრავის, პროვაიდერის, წესების, ფიჩებისა და რეალობის ვერსიები.

17) განხორციელების შემოწმების სია

ორკესტრი ფაილოვერით და იურისდიქციით როუტინგი.
ხელშეკრულებები/SLA/ფასების, DPIA და იურიდიული დამტკიცებები.
ვებჰუკი, idempotence, retrai, tracing.
Case მენეჯმენტი და playbuks EDD.
Periodic re-screen (სანქციები/REP) და ღონისძიება-დარტყმა.
ხარისხის მონიტორინგი (hit-rate, FPR/FNR, გავლის დრო).
retention/მოცილებისა და წვდომის პოლიტიკა (RBAC).
DR გეგმა და დეგრადაციის სწავლებები.

რეზიუმე

ძლიერი KYC/AML ინტეგრაცია არ არის „ერთი პროვაიდერის დაკავშირება“, არამედ ორკესტრის აშენება რამდენიმე წყაროდან, სადაც გადაწყვეტილებები მიიღება რისკზე დაფუძნებული, გამჭვირვალე და სწრაფად. დააკავშირეთ IDV, Liveness, სანქციები/REP და მისამართი, შემოიღეთ კასეტის მენეჯმენტი და მკაცრი აუდიტი, შეინარჩუნეთ ფოლკლორული პროვაიდერები და არ დაივიწყოთ UX- ს შესახებ - ასე რომ თქვენ დააკმაყოფილებთ რეგულატორების მოთხოვნებს და შეინარჩუნებთ ონბორდის მაღალ კონვერტაციას.