ادغام ارائه دهندگان قوانین سفر

1) هدف از ادغام

• حمایت از مدل IVMS101 متعارف،
• یک لایه آداپتور به ارائه دهنده،
• ارائه امنیت (mTLS، امضا، رمزگذاری) و SLA ها،
• پوشش hosted↔hosted و سیاست برای unposted.

2) انتخاب پروتکل/ارائه دهنده: مدل

2. 1 پروتکل ها و شبکه های اعتماد

TRISA/TRP/OpenVASP - P2P/فدراسیون با PKI، دایرکتوری VASP، تایید تحویل.
هاب های تجاری/aggregators - حمل و نقل انتزاعی، به کشف و مسیریابی.

2. 2 معیارهای انتخاب (خلاصه)

پوشش صلاحیت/VASP، دایرکتوری/کیفیت کشف.

سازگار با IVMS101 و افزونه ها

ایمنی (PKI، mTLS، امضا)، تاخیر/SLA، عقب نشینی/quorums.
هزینه هر پیام/حجم، گزارش و حسابرسی.
پشتیبانی از سیاست های ناخوشایند (اعتبار سنجی مالکیت آدرس)، sandbox و صدور گواهینامه.

3) معماری مرجع ادغام

1. Payments Core انتقال رمزنگاری را آغاز می کند.

2. هماهنگ کننده انطباق → تصمیم می گیرد که آیا یک قانون سفر (آستانه/نوع جغرافیایی/نوع متقابل) مورد نیاز است.

3. دروازه قانون سفر (خدمات شما)

مدل IVMS101 متعارف ؛

آداپتورهای آنان به TRISA/TRP/OpenVASP/aggregator ؛

امضا/رمزگذاری، idemotency، retrays/سهمیه.
4. Directory/Discovery → جستجوی متقابل، اعتبار سنجی گواهی/سیاست.
5. KYT/موتور تحریم → قبل از بررسی قبل از مبادله.
6. PII Vault → ذخیره سازی زمینه های شخصی، نشانه گذاری، RBAC/حسابرسی.

1. ایجاد یک درخواست → 2) TAC/قبل از بررسی تحریم → 3) کشف VASP → 4) تبادل IVMS101 (درخواست/پاسخ) → 5) اجازه/نگه/رد راه حل → 6) پخش آنلاین → 7) سیاهههای مربوط/گزارش.

4) مدل داده کانونی (IVMS101)

• مبدأ: نام، شناسه، کشور/آدرس یا DOB، شناسه حساب/کیف پول.
• ذینفع: نام (при VASP)، شناسه حساب/کیف پول.
• معامله: دارایی، زنجیره ای، مقدار، برچسب زمان، شناسه انتقال داخلی.
• استانداردهای انطباق: شناسه چک KYT، شناسه صفحه نمایش تحریم، شناسه پیام قانون سفر.

تمرین: IVMS101 را به عنوان «مدل متعارف» در پایگاه داده خود ذخیره کنید. آداپتورها تبدیل به یک پروتکل خاص می شوند.

5) امنیت و اعتماد

mTLS با احراز هویت متقابل (PKI/دایرکتوری).
امضای پیام و رمزگذاری محتوای پایان به پایان (PII).
RBAC/SoD: نقش های تقسیم شده برای ارسال/تصویب/صادرات داده ها.
سیاهههای مربوط/غیر قابل تغییر سیاهههای مربوط: چه کسی/چه/زمانی که ارسال, نسخه طرح.

6) کشف/دایرکتوری

جستجوی طرف مقابل توسط شناسه VASP، دامنه، LEI/BIC (در صورت موجود بودن).
ذخیره سازی ضبط، چرخش گواهی، لیست CA قابل اعتماد.
کانال Folback: درخواست برای تایید جزئیات از طریق یک جمع کننده یا «پل» (در صورت اجازه توسط سیاست).

7) کنترل جریان و SLA

• کشف + تبادل p95: ≤ 60-120 с.
• Pre-KYT p95: ≤ 5-15 с.
• راه حل خودکار: ≤ 2-5 دقیقه، دستی با خطر بالا: ≤ 4 ساعت.

• عقب نشینی نمایشی + لرزش ؛ 'travel _ rule _ message _ id'.
• خودکار سوئیچ به آداپتور/هاب آماده به کار در صورت تخریب.
• تاییدیه خواندن/تحویل (ACK/NACK)

8) دست زدن به خطا (playbook)

9) سیاست برای کیف پول های ناخواسته

تأیید مالکیت آدرس (امضا، «proof-microtransfer»).

KYT قبل از ثبت نام و قبل از خروج ؛ محدودیت های بخش

کتاب آدرس/لیست سفید با TTL و اصلاح دوره ای.
مستندات استثنائات RBA (مقادیر کوچک/کم خطر) - در صورت قانونی.

10) PII خرک و حریم خصوصی

PII را از گزارش معاملات و داده های پرداخت جدا کنید.
رمزگذاری (KMS/HSM)، نشانه گذاری شناسه ها، دسترسی نیاز به دانستن.
نگهداری توسط صلاحیت (اغلب 5 + سال)، خودکار انقضا، روش DSR.
نسخه بندی طرح های IVMS101 و پیگیری حسابرسی برای هر مبادله.

11) الگوهای ادغام

11. 1 لایه آداپتور

رابط: 'ارسال (ivms_payload) -> ack '/' دریافت () -> ivms_payload'.
تبدیل: IVMS101 ⇄ یک فرمت خاص (TRISA/TRP/OpenVASP/هاب).
نسخه های API، وب سایت های امضا شده، بازپرداخت قطعی.

11. 2 راه حل های انطباق

Матрица RBA: 'allow '/' limit '/' hold '/' reject '/' escalate'.
آزادی جزئی اگر بخشی از بودجه «تمیز» باشد.
پیوند با KYT: قانون سفر را در مسیرهای ظاهرا ممنوع ارسال نکنید.

11. 3 قابلیت اطمینان

دو یا چند ارائه دهنده/پروتکل از طریق یک دروازه واحد.
چک های بهداشتی، قطع کننده مدار، هشدارهای زمان واقعی.

12) تست و راه اندازی

ارائه دهنده Sandbox + شبیه ساز طرف مقابل خود را.
مجموعه مورد: داده های کامل/ناقص، زمان بندی، عدم تطابق، بی اعتمادی PKI.
تست بار (اوج مسابقات/تبلیغات)، اندازه گیری P50/P95/تلفات.
آموزش پرداخت/ریسک/پشتیبانی: اسکریپت برای برقراری ارتباط با مشتریان.

13) معیارها و داشبورد

درصد پوشش: سهم نقل و انتقالات VASP↔VASP با یک مبادله موفق.
SLA نرخ ضربه по کشف/تبادل/تصمیم گیری.
تلاش مجدد/نرخ شکست، причины (timeout/عدم تطابق/پشتیبانی نشده/اعتماد).
نگه دارید/رد٪ و متوسط زمان باز کردن.
شکایت/نرخ بلیط توسط قانون سفر، خروجی NPS.
هزینه هر مبادله (همه در): ارائه دهنده + اپرا. زمان.

14) ضد الگوهای

Onchain-اعزام برای تکمیل قانون سفر که در آن «قبل از انتقال» مورد نیاز است.
یک کراوات سخت برای یک ارائه دهنده بدون انتزاع آداپتور.
ذخیره سازی PII در سیاهههای مربوط/تجزیه و تحلیل مشترک بدون tokenization.
فقدان idempotency → پیام های تکراری/راه حل.
نادیده گرفتن تأیید سیاست و تأیید آدرس.
نسخهبندی طرحواره/فهرست راهنما → راهحلهای «غیرقابل تکرار» وجود ندارد.

15) RFP/چک لیست پیاده سازی (کوتاه)

• پشتیبانی از IVMS101 (زمینه های اجباری/اختیاری)، اعتبار سنجی.
• پروتکل (ها): TRISA/TRP/OpenVASP، جمع کننده ها ؛ کشف/دایرکتوری и PKI.
• امنیت: mTLS، امضا/رمزگذاری، ثبت فعالیت، وب سایت های امضا شده.
• SLA/retrai: اهداف p95، عقب نشینی + جرقه، قطع کننده مدار، feilover.
• سازگاری QT/تحریم، API قبل از بررسی و همبستگی مورد.
• Unposted-سیاست: تایید آدرس، لیست سفید با TTL، محدودیت.
• PII خرک: رمزگذاری، RBAC/SoD، حفظ/DSR، حسابرسی.
• گزارش: مصنوعات مبادله، نسخه های طرح/برچسب، صادرات برای SAR/STR.
• Sandbox/Simulators، تست های بارگیری و خرابی.
• آموزش تیم و قالب های ارتباطی مشتری.

16) خلاصه

یکپارچه سازی قوانین سفر یک معماری دروازه با IVMS101 به عنوان یک مدل متعارف، Discovery/PKI برای اعتماد، آداپتورهای چند ارائه دهنده و قوانین امنیتی/PII دقیق است. آن را به راه حل های KYT و RBA پیوند دهید، یک سیاست را برای unsoosted بنویسید، SLA/feilover و UX شفاف ارائه دهید - و پرداخت ها/سپرده های رمزنگاری شما بدون به خطر انداختن سرعت و تبدیل، الزامات را برآورده می کند.