داده‌های نسخه طلایی و هوش مصنوعی در فرآیند چرخه عمر معامله

فرآیند فعلی سرتاسری چرخه عمر معامله به شدت به داشتن داده‌های دقیق در هر مرحله وابسته است. هدف سیستم دفتر ثبت سرمایه‌گذاری (IBOR یا Investment Book of Records) اطمینان از تطابق داده‌های معامله، موقعیت (Position) و نقدینگی با داده‌های متولی (Custodian) است و برای سیستم دفتر ثبت حسابداری (ABOR یا Accounting Book of Records)، هدف تطابق همین مجموعه داده با داده‌های حسابدار صندوق (Fund Accountant) است.

ذینفعان دیگری نیز در این فرآیند وجود دارند، از جمله سیستم‌های کارگزاران، نمایندگان نقل و انتقال (Transfer Agents)، طرف‌های تسویه مرکزی (Central Clearing Parties) و غیره، بسته به نوع و مکان اجرای معامله. موقعیتی که به طور یکسان در تمام سیستم‌ها منعکس شود، به عنوان «پردازش مستقیم و بدون وقفه» (Straight-Through Processed یا STP) شناخته می‌شود؛ به عبارت دیگر، سیستم‌ها معامله را شناسایی کرده‌اند و مجموعه‌داده‌ها با هم هماهنگ هستند یا حداقل در محدوده تحمل (Tolerance) قرار دارند.

در حالی که این فرآیند کارآمد است، رسیدگی و حل نهایی معاملات غیر STP (Non-STP) همچنان به شدت دستی انجام می‌شود. ذینفعان معمولاً نقاط داده را در چندین سیستم مقایسه می‌کنند، تا حد امکان از مراحل اولیه شروع کرده و به تدریج در طول چرخه عمر به سمت علت اصلی مغایرت (Break) حرکت می‌کنند. این بررسی زمان‌بر است، در سراسر زنجیره ارزش اختلال ایجاد می‌کند و مهم‌تر از همه، برای دفتر معاملات (Front Office) در تصمیم‌گیری‌های جدید، عدم قطعیت ایجاد می‌کند.

پیشنهاد این است که از هوش مصنوعی (AI) برای ایجاد و پالایش مداوم داده‌های نسخه طلایی (Gold-Copy Data) در هر مرحله از چرخه عمر از طریق مقایسه با منابع استفاده شود و فرآیندهای پایین‌دستی به گونه‌ای مرتبط شوند که به طور خودکار و در زمان واقعی با مجموعه‌داده‌های دقیق به‌روز شوند. همچنین باید حفاظ‌هایی (Guardrails) برای موارد تفاوت‌های بااهمیت (Material Differences) پیاده‌سازی شود.

بیایید فرآیند فعلی را با یک مثال تحلیل کنیم - یک اوراق قرضه ساده (Vanilla Bond) در شرف انجام یک رویداد شرکتی (Corporate Action) از نوع پرداخت غیرنقدی (PIK یا Payment-In-Kind) است (PIK زمانی رخ می‌دهد که ناشر تصمیم می‌گیرد بهره‌ای را که باید به صورت نقدی پرداخت می‌کرد، به عنوان اوراق بهادار اضافی سرمایه‌ای کند). فرض کنید فروشنده‌ای (Vendor) که سیستم IBOR از آن استفاده می‌کند، از روش شمارش روز ACT/360 (برای محاسبه تعهدی) استفاده می‌کند، در حالی که متولی از ACT/365 استفاده می‌کند:

• در تاریخ موثر (Ex-date)، رویداد PIK با سرمایه‌ای‌شدن بالاتری نسبت به متولی پردازش می‌شود و مغایرتی بین IBOR و بانک ایجاد خواهد شد.
• این مغایرت ابتدا در تاریخ موثر کشف می‌شود، با فرض اینکه بانک پیام MT567 (وضعیت رویداد شرکتی) را ارسال کرده و تفاوت موقعیت بین دو سیستم را نشان دهد.
• سپس، در روز تسویه + ۱ (SD+1)، این موضوع دوباره هنگام ارسال پیام MT535 (صورت وضعیت موقعیت) توسط بانک، که مغایرت را در حین تطبیق موقعیت نشان می‌دهد، مشخص خواهد شد.
• در نهایت، اگر حسابداری سرمایه‌گذاری در تاریخ موثر یا SD+1 اجرا شود، مغایرتی بین IBOR و حسابدار صندوق وجود خواهد داشت، جایی که ترازنامه و صورت تغییرات در خالص ارزش دارایی‌ها (Statement of Change in Net Asset) دوباره یک استثنا (Exception) برای آن اوراق بهادار نشان خواهند داد.

این مثال ساده نشان می‌دهد که چگونه یک مغایرت در مراحل اولیه چرخه عمر، باعث ایجاد سه مغایرت جداگانه در زنجیره پایین‌دستی می‌شود؛ به عبارت دیگر، سه بخش مختلف از کاربران (کاربر رویداد شرکتی، کاربر تطبیق، و کاربر حسابداری) همگی در حال بررسی یک علت ریشه‌ای یکسان هستند.

هنگامی که داده‌های سیستم IBOR اصلاح شد، هر یک از این بخش‌های کاربری باید منطق آبشاری (Waterfall Logic) را برای به‌روزرسانی هر یک از سیستم‌ها/فرآیندهای پایین‌دستی هماهنگ کنند.

متأسفانه، چنین اتفاقاتی رایج هستند. با یکپارچه‌تر شدن سیستم‌های سرمایه‌گذاری از مرحله پیش‌معاملاتی تا پس‌معاملاتی (Front-to-Middle-to-Back)، داده‌های نادرست در هر نقطه از زنجیره فرآیند، باعث ایجاد ناکارآمدی در تعدادی از بخش‌های کاربری می‌شود و کاربران متعددی را مجبور می‌کند تا همان استثنا (یا تأثیر آن استثنا) را در ابزارهای مربوطه خود تجزیه و تحلیل کنند.

کاربران پایین‌دستی که در حال تطبیق با بانک یا حسابدار صندوق هستند، مغایرت اوراق بهادار را متوجه خواهند شد، اما ممکن است فوراً علت اصلی تفاوت در روش شمارش روز را تشخیص ندهند. این کاربران معمولاً برای بررسی، وظایف زیر را انجام می‌دهند:

• ارسال استعلام به بانک در مورد صورت وضعیت MT535 برای توضیح تفاوت موقعیت.
• ارسال استعلام به حسابدار صندوق در مورد صورت وضعیت برای توضیح تفاوت موقعیت.
• ارسال استعلام به تیم داده داخلی برای مشخص کردن محاسبات موقعیت IBOR.
• پس از آگاهی از یک رویداد شرکتی اخیر، ارسال استعلام به تیم داخلی رویدادهای شرکتی (COAC) برای بررسی پردازش PIK.

همانطور که مشاهده می‌شود، انرژی و ظرفیت تیم‌های متعددی برای بررسی علت ریشه‌ای صرف می‌شود و همه این کارها به صورت دستی انجام می‌شود.

از سوی دیگر، یک فرآیند هوش مصنوعی که می‌تواند به طور مداوم مجموعه‌داده‌های چند منبعی را استعلام کند، باید می‌توانست به طور پیشگیرانه مغایرت شمارش روز را قبل از پردازش رویداد شرکتی شناسایی کند، و همچنین به طور خودکار تیم‌های پایین‌دستی را از نادرستی بالقوه در موقعیت خاص اوراق بهادار PIK مطلع سازد.

در حالی که هرگونه تغییر در داده‌های کاربر توسط هوش مصنوعی همچنان باید تحت بررسی یک بازبین قرار گیرد، چنین تشخیص و ارتباط پیشگیرانه‌ای به طور چشمگیری زمان حل مشکل را افزایش داده و باید باعث کاهش سرخوردگی کاربر شود.

بیایید گردش کار رویداد شرکتی را با جزئیات بیشتری بررسی کنیم. کاربران معمولاً پس از «پاکسازی» (Scrubbing) داده‌ها از منابع متعدد و ایجاد یک نسخه دقیق و به‌روز از رویدادی که قرار است رخ دهد، یک رویداد «نسخه طلایی» (Gold-Copy) ایجاد می‌کنند. این از بسیاری جهات ایده‌آل است: پاکسازی منابع متعدد تضمین می‌کند که احتمال دریافت فید نادرست از یک فروشنده واحد کمتر است و شکاف‌های فرآیندی را کاهش می‌دهد.

ما به هوش مصنوعی نیاز داریم تا این فرآیند را به طور مداوم انجام دهد. سیستم‌های IBOR باید حداقل مشترک دو یا چند فروشنده باشند که داده‌ها باید از آنها بازیابی شوند. هرگونه تغییر در مجموعه‌داده باید به طور مداوم (از طریق مکانیزم API فشاری (Push) یا کششی (Pull)) به‌روز شود. این به صورت زیر عمل می‌کند:

• یک اوراق بهادار عمومی جدید در بازار با شناسه‌های عمومی از جمله CUSIP، ISIN، SEDOL و غیره راه‌اندازی می‌شود.
• فروشندگان داده‌ای که فید را به سیستم‌های IBOR ارائه می‌دهند، باید پس از تکمیل جزئیات حداقل نقاط داده مورد نیاز، این اطلاعات را به طور خودکار ارسال کنند.
  • سیستم‌های IBOR، در این مرحله، این اوراق بهادار را در سیستم‌های داده خود ایجاد می‌کنند.
  • هرگونه مغایرت بین فروشندگان باید توسط یک کاربر بررسی شود و مقادیر مناسب (در صورت لزوم) انتخاب شوند.
• هرگونه به‌روزرسانی که اوراق بهادار از آن نقطه به بعد در بازار متحمل می‌شوند، باید به طور خودکار ثبت شده و اوراق بهادار در سیستم IBOR به‌روز شوند.
  • در این مرحله، برنامه‌های کاربردی پایین‌دستی که از این برنامه استفاده می‌کنند، باید به طور خودکار یک به‌روزرسانی بازار اوراق بهادار و به‌روزرسانی مبتنی بر رویداد قریب‌الوقوع را نشان دهند.
    • این به کاربران اطلاع می‌دهد که مجموعه‌داده‌ای که می‌بینند ممکن است در مقایسه با فرآیندهای خارجی که ممکن است داده‌های به‌روز دریافت کنند، قدیمی باشد.
  • برای محافظت در برابر خطر داده‌های نادرست از یک فروشنده واحد، فقط مجموعه‌داده‌ای که در بین همه فروشندگان سازگار است باید به طور خودکار به‌روز شود.
  • به‌روزرسانی‌های داده از یک فروشنده واحد باید برای بررسی و تأیید به کاربر ارائه شود.
• هنگامی که اوراق بهادار زیربنایی به‌روز شدند، این به عنوان یک «رویداد» در نظر گرفته می‌شود که باید باعث به‌روزرسانی تمام برنامه‌های کاربردی پایین‌دستی شود که به به‌روزرسانی اوراق بهادار متکی هستند (به‌روزرسانی‌های مبتنی بر رویداد).
  • به‌روزرسانی‌های مبتنی بر رویداد، تعداد لمس‌های دستی (Manual Touches) را که کاربران پایین‌دستی برای رفع نادرستی‌های شناسایی شده در بالادست نیاز دارند، به شدت کاهش می‌دهد.
  • هنگامی که تمام برنامه‌های کاربردی با مجموعه‌داده‌های به‌روز شده هماهنگ شدند، پرچم به‌روزرسانی بازار اوراق بهادار باید به طور خودکار حذف شود.

اگرچه هیجان‌انگیز است، استفاده از هوش مصنوعی و به‌روزرسانی‌های مبتنی بر رویداد، چند نگرانی را ایجاد می‌کند که ارزش بحث دارند - ظرفیت/ذخیره‌سازی داده، تفاوت‌های زمانی بالقوه با شرکت‌کنندگان خارجی، و اهمیت/تحمل (Materiality/Tolerance).

بیایید ابتدا به مورد آخر بپردازیم - اهمیت/تحمل. اوراق بهادار ممکن است گهگاه دستخوش تغییرات بی‌اهمیتی شوند که تأثیر کمی بر تمام فرآیندهای بالادستی و پایین‌دستی در چرخه عمر معامله داشته باشند یا اصلاً تأثیری نداشته باشند.

در نتیجه، مجموعه‌ای از فیلدها و محدوده‌های تحمل باید شناسایی شوند تا در صورت به‌روزرسانی‌های بازار نشان داده شوند (مجموعه داده اصلی یا Core Dataset). اگر به‌روزرسانی‌ها روی این فیلدهای خاص رخ دهند و خارج از محدوده تحمل موجود باشند، سیستم‌های IBOR باید به‌روزرسانی‌های ارائه شده توسط فروشندگان را مصرف کنند.

اگر به‌روزرسانی‌ها روی هر فیلد دیگری رخ دهند (یا در محدوده تحمل باشند)، به‌روزرسانی‌ها باید رد شوند. این تضمین می‌کند که سیستم از کارایی هوش مصنوعی بدون ناکارآمدی ناشی از اختلال (Noise) بهره می‌برد.

ثانیاً، پتانسیل تفاوت‌های زمانی با شرکت‌کنندگان خارجی وجود دارد. در حالی که سیستم IBOR ممکن است داده‌های به‌روز داشته باشد، شرکت‌کنندگان خارجی (به عنوان مثال، بانک‌ها یا سیستم‌های حسابداری صندوق) ممکن است به استفاده از مجموعه‌داده‌های قدیمی یا منسوخ ادامه دهند.

باید یک سابقه ممیزی (Audit History) از داده‌های تاریخی مجموعه داده اصلی در دسترس باشد؛ به عبارت دیگر، اگر سیستم بانک/حسابداری صندوق به هر یک از مجموعه‌داده‌های ممیزی اشاره کند، یک یادداشت خودکار باید به شرکت‌کننده خارجی ارسال شود که آنها را از داده‌های قدیمی مطلع کرده و درخواست کند که مجدداً با فروشندگان بازار خارجی بررسی کنند.

در نهایت، نگرانی در مورد ظرفیت داده وجود دارد. شکی نیست که استعلام، اعتبارسنجی و به‌روزرسانی مداوم مجموعه داده‌های اصلی توسط چندین فروشنده، همراه با نگهداری داده‌های ممیزی، هزینه‌های مصرف و ذخیره‌سازی داده را افزایش می‌دهد.

تعدادی از شرکت‌ها طبق قانون ملزم به نگهداری سابقه ممیزی حداقل به مدت پنج سال هستند و افزودن الزامات فوق قطعاً نیاز به ظرفیت را افزایش می‌دهد. محدود کردن به‌روزرسانی‌های اوراق بهادار صرفاً به مجموعه داده‌های اصلی و در نظر گرفتن محدوده تحمل، باید به مدیریت بخشی از این ظرفیت مورد نیاز کمک کند.

علیرغم این نگرانی‌های جدی برجسته شده، استفاده از هوش مصنوعی همچنان برای طراحی و پیاده‌سازی در سراسر فرآیند چرخه عمر معامله ارزشمند است و به طور قابل توجهی ارزشمندتر از هزینه‌هایی خواهد بود که احتمالاً متحمل می‌شوند. در حالی که بسیاری از مثال‌های این مقاله به اوراق بهادار عمومی پرداخته‌اند، دامنه کاربرد در اوراق بهادار خصوصی با داده‌های با کیفیت بسیار پایین‌تر، به طور قابل توجهی گسترده‌تر است.

با توجه به اینکه دنیای سرمایه‌گذاری به سمت افزایش سرمایه‌گذاری در اوراق بهادار خصوصی در حال گذار است، بهره‌گیری از هوش مصنوعی همچنان در هر دو حوزه سودمند خواهد بود.