Travel Rule პროვაიდერების ინტეგრაცია

1) ინტეგრაციის მიზანი

• მხარი დაუჭირეთ კანონიკურ მოდელს IVMS101,
• გქონდეთ აგნოსტიკური Adapter ფენის პროვაიდერის მიმართ,
• უსაფრთხოების უზრუნველყოფა (mTLS, ხელმოწერა, დაშიფვრა) და SLA,
• დაფარეთ hosted და პოლიტიკა unhosted.

2) პროტოკოლის/პროვაიდერის არჩევანი: მოდელები

2. 1 ოქმები და ნდობის ქსელები

TRISA/TRP/OpenVASP - p2R/ფედერაცია PKI- ით, VASP კატალოგებით, მიწოდების დადასტურებით.
კომერციული ჰაბები/აგრეგატორები - აბსტრაქტული ტრანსპორტი, აძლევენ Discovery და მარშრუტიზაციას.

2. 2 არჩევანის კრიტერიუმები

იურისდიქციების დაფარვა/VASR, Directory/Discovery ხარისხი.
თავსებადობა IVMS101 და გაფართოებებთან.
უსაფრთხოება (PKI, mTLS, ხელმოწერა), latency/SLA, retrai/quorums.
გზავნილის/მოცულობის ღირებულება, ანგარიში და აუდიტი.
მხარდაჭერა უნებართვო პოლიტიკაში (მისამართის საკუთრების შესაბამისობა), სანდბოქსი და სერტიფიკაცია.

3) რეფერენდუმი-ინტეგრაციის არქიტექტურა

1. Payments Core - იწყებს კრიპტოვალუტას.

2. Compliance Orchestrator გადაწყვეტს, საჭიროა თუ არა Travel Rule (ბარიერი/გეო/ტიპის კონტრარგუმენტი).

3. Travel Rule Gateway (თქვენი მომსახურება)

კანონიკური IVMS101 მოდელი;

Adapters TRISA/TRP/OpenVASP/აგრეგატორისთვის;

ხელმოწერა/დაშიფვრა, idempotence, retrai/კვოტები.
4. Discovery/Discovery - კონტრარგუმენტების ძებნა, სერთიფიკატების/პოლიტიკოსის შესაბამისობა.
5. KYT/Sanctions Engine - pre შემოწმება გაცვლამდე.
6. PII Vault - პერსონალური ველების შენახვა, ტოქსიკაცია, RBAC/აუდიტი.

1. განაცხადის შექმნა (2) KUT/სანქციები Pre-check (3) Discovery VASP (4) გაცვლა IVMS101 (response) (5) გადაწყვეტილება ალოუ/hold/reeject/6) ონჩეინის ბროადკასტი (7) ლოგა/მოხსენება.

4) კანონიკური მონაცემთა მოდელი (IVMS101)

• Originator: name, identifier, country/address or DOB, account/wallet id.
• Beneficiary: name (при VASP), account/wallet id.
• Transaction: asset, chain, amount, timestamp, internal transfer id.
• Compliance refs: KYT check id, sanctions screen id, Travel Rule message id.

პრაქტიკა: შეინახეთ IVMS101, როგორც „კანიონური მოდელი“ თქვენს მონაცემთა ბაზაში; გადამყვანები გარდაქმნიან კონკრეტულ პროტოკოლს.

5) Security & Trust

mTLS ურთიერთგაგებით (PKI/Directive).
შეტყობინებების ხელმოწერა და შინაარსის დაშიფვრა (PII).
RBAC/SoD: მონაცემთა გაგზავნის/დამტკიცების/ექსპორტის როლების გამიჯვნა.
ჟურნალები/უცვლელი ლოგოები: ვინ/რა/როდის გაგზავნა, სქემის ვერსია.

6) Discovery/Directory

VASP იდენტიფიკატორის, დომენის, LEI/BIC კონტრაგენტის ძებნა (სადაც ხელმისაწვდომია).
ჩანაწერების შევსება, სერთიფიკატების როტაცია, CA სანდო სია.
ფოლკლორული არხი: მოთხოვნა, რომ დაადასტუროს დეტალები აგრეგატორის ან „ხიდის“ მეშვეობით (თუ ეს ნებადართულია პოლიტიკით).

7) ნაკადის კონტროლი და SLA

• Discovery + exchange p95: ≤ 60–120 с.
• Pre-KYT p95: ≤ 5–15 с.
• Auto-case- ის გამოსავალი: 2-5 წუთი, სახელმძღვანელო High-risk: 4 სთ.

• ექსპონენტური backoff + ჯიტერი; იდეპოტენტურობა 'travel _ rule _ message _ id'.
• დეგრადაციის დროს სარეზერვო adapter/კერა ავტოპარკი.
• მიწოდების/წაკითხვის დადასტურების კვორუმი (ACK/NACK).

8) შეცდომის დამუშავება (playbook)

9) პოლიტიკა unhosted საფულეებისთვის

მისამართის საკუთრების დადასტურება (ხელმოწერა, „მიკროავტობუსი“).
KYT ჩარიცხვამდე და დასკვნამდე; სეგმენტების ლიმიტები.
Address book/whitelist ერთად TTL და პერიოდული გადახედვა.
აღწერეთ RBA- ს გამონაკლისები (მცირე თანხები/დაბალი რისკი) - სად არის ეს კანონიერი.

10) PII Vault და კონფიდენციალურობა

გამოყავით PII ოპერაციული ლოგოებისა და გადახდის მონაცემებისგან.
დაშიფვრა (KMS/HSM), იდენტიფიკატორის ტოქსიკაცია, დაშვება.
Retention იურისდიქციით (ხშირად 5 + წელი), ავტომობილების ექსპორტი, DSR პროცედურები.
IVMS101 სქემების ვერსია და audit trail თითოეული გაცვლისთვის.

11) ინტეგრაციის ნიმუშები

11. 1 ადაპტერი ფენა

ინტერფეისი: 'send (ivms _ payload) -> ack '/' receive () -> ivms _ payload'.
ტრანსფორმაციები: IVMS101 - კონკრეტული ფორმატი (TRISA/TRP/OpenVASP/კერა).
API- ს ვერსია, ხელმოწერილი ვებჰუკები, დეტერმინისტული განმეორებითი გაგზავნა.

11. 2 კომპლექსური გადაწყვეტილებები

Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.
წვეულება გაწმენდა თუ სახსრების ნაწილი „სუფთაა“.
KYT- სთან ერთად: ნუ გაგზავნით მოგზაურობას Rule აშკარად აკრძალულ მარშრუტებზე.

11. 3 საიმედოობა

ორი ან მეტი პროვაიდერი/პროტოკოლი ერთი Gateway- ის საშუალებით.
Health checks, circuit-breaker, real-time ალერტები.

12) ტესტირება და ექსპლუატაცია

Sandbox პროვაიდერი + თქვენი კონტრაგენტის სიმულატორი.
საქმეების ნაკრები: სრული/არასრული მონაცემები, ტაიმაუტები, mismatch, PKI- ს უნდობლობა.
დატვირთვის ტესტები (პიკის ტურნირები/აქციები), გაზომეთ p50/p95/ზარალი.
Payments/Risk/Support ტრენინგი: მომხმარებლებთან კომუნიკაციის სკრიპტები.

13) მეტრიკი და დაშბორდი

Coverage%: VASP წილი არის VASP გადარიცხვები წარმატებული გაცვლით.
SLA hit rate по Discovery/Exchange/Decision.
Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).
Hold/Reject% და განბლოკვის საშუალო დრო.
Complaint/Ticket rate Travel Rule, NPS გამომავალი.
Cost per Exchange (all-in): პროვაიდერი + ოპერა. დრო.

14) ანტი შაბლონები

Onchein გაგზავნა Travel Rule- ის დასრულებამდე, სადაც საჭიროა „pre transfer“.
მკაცრი კავშირი ერთ პროვაიდერზე Adapter აბსტრაქციის გარეშე.
PII- ის შენახვა საერთო ლოგოებში/ანალიტიკაში ტოკენიზაციის გარეშე.
იდემპოტენტურობის არარსებობა - შეტყობინებების/გადაწყვეტილებების დუბლირება.
უნებართვო პოლიტიკის უგულებელყოფა და მიზნობრივი გადამოწმება.
არ არსებობს სქემების/კატალოგების ვერსია, „უნიკალური“ გადაწყვეტილებები.

15) RFP/განხორციელების ჩეკის სია (მოკლედ)

• მხარდაჭერა IVMS101 (სავალდებულო/არჩევითი ველები), ვალიდაცია.
• პროტოკოლი (s): TRISA/TRP/OpenVASP, აგრეგატორები; Discovery/Directory и PKI.
• უსაფრთხოება: mTLS, ხელმოწერა/დაშიფვრა, სამოქმედო ჟურნალი, signed webhooks.
• SLA/retrai: მიზნები p95, backoff + jitter, circuit-breaker, faylover.
• თავსებადობა KUT/სანქციებთან, pre-check API და შემთხვევების კორელაცია.
• უნებართვო პოლიტიკა: მისამართის დადასტურება, whitelist TTL- დან, ლიმიტები.
• PII Vault: დაშიფვრა, RBAC/SoD, retention/DSR, აუდიტი.
• ანგარიშები: გაცვლითი ნიმუშები, სქემების/ეტიკეტების ვერსიები, ექსპორტი SAR/STR- სთვის.
• Sandbox/სიმულატორები, დატვირთვა და წინააღმდეგი ტესტები.
• გუნდების ტრენინგი და მომხმარებლებთან კომუნიკაციის შაბლონები.

16) რეზიუმე

Travel Rule- ის ინტეგრაცია არის gateway არქიტექტურა IVMS101, როგორც კანონიკური მოდელი, Discovery/PKI ნდობისთვის, ადაპტერი რამდენიმე პროვაიდერთან და მკაცრი უსაფრთხოების წესებით/PII. დააკავშირეთ იგი KYT- სა და RBA- ს გადაწყვეტილებებთან, დაწერეთ პოლიტიკა unhosted- ისთვის, უზრუნველყეთ SLA/Failover და გამჭვირვალე UX - და თქვენი კრიპტო გადახდები/დეპოზიტები დააკმაყოფილებენ მოთხოვნებს სიჩქარისა და კონვერტაციისთვის ზიანის მიყენების გარეშე.