معماری مدیریت پورتفولیو مبتنی بر هوش مصنوعی در Orion، Black Diamond، Addepar و موتورهای ریسک مستقل

تصمیم معماری پیش روی RIAs در حال رشد، به ندرت در مورد استفاده از Orion، Black Diamond یا Addepar به صورت جداگانه است. این تصمیم در مورد چگونگی ترکیب آنها با یکدیگر، با موتورهای ریسک مستقل و با زیرساخت‌های عامل سفارشی در پیکربندی است که با واقعیت عملیاتی شرکت مطابقت دارد. هر پلتفرم بخش کوچکی از مشکل مدیریت پورتفولیو را به خوبی مدیریت می‌کند و هر یک دارای شکاف‌هایی هستند که دقیقاً در جایی که سایر پلتفرم‌ها نقاط قوت دارند، ظاهر می‌شوند. معماری ابزارهای مدیریت پورتفولیو مبتنی بر هوش مصنوعی در این سیستم‌ها، یک سؤال روش‌شناسی است تا یک سؤال انتخاب فروشنده، و شرکت‌هایی که روش‌شناسی را به درستی انجام می‌دهند، در نهایت با پشته‌هایی مواجه می‌شوند که اهرم عملیاتی را در طول زمان افزایش می‌دهند.

چرا استراتژی‌های تک پلتفرمی به سقف‌هایی برخورد می‌کنند که استراتژی‌های چند پلتفرمی از آن اجتناب می‌کنند

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

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

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

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

چگونه معماری در اطراف تراکم عملیاتی Orion را طراحی کنیم

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

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

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

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

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

نقاط قوت جریان کار Black Diamond چه معنایی برای تصمیمات معماری دارد

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

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

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

معماری یکپارچه‌سازی بین Black Diamond و سیستم‌های بازتوازن خارجی نیاز به توجه دقیق به وضعیت موقعیت دارد. معاملات اجرا شده از طریق سیستم بازتوازن باید تقریباً در زمان واقعی به گزارش‌دهی Black Diamond منتقل شوند و ناهماهنگی‌های تطبیق بین دو سیستم مشکلات گزارش‌دهی ایجاد می‌کند که مستقیماً در ارتباطات مشتری ظاهر می‌شود.

لایه مستندات رعایت مقررات در Black Diamond، مانند Orion، کاربردی است اما تخصصی نیست. شرکت‌هایی که مستندات رعایت مقررات جداگانه را از طریق زیرساخت عامل ایجاد می‌کنند، معمولاً سوابق حسابرسی قابل دفاع‌تری نسبت به آنچه پلتفرم عمومی تولید می‌کند، به ویژه برای ارائه عملکرد تحت قانون بازاریابی SEC، تولید می‌کنند.

عمق جمع‌آوری Addepar چگونه معماری دفتر خانواده را شکل می‌دهد

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

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

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

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

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

زمانی که یک موتور ریسک مستقل در پشته قرار می‌گیرد

موتورهای ریسک مستقل مانند Aladdin تجزیه ریسک چند دارایی را با عمقی مدیریت می‌کنند که ماژول‌های ریسک یکپارچه در Orion، Black Diamond و Addepar با آن مطابقت ندارند. سؤال معماری این است که چه زمانی هزینه و پیچیدگی اضافی یک موتور مستقل با عمقی که ارائه می‌دهد، توجیه می‌شود.

روش‌شناسی پاسخ به این سؤال با استراتژی سرمایه‌گذاری شرکت آغاز می‌شود. شرکت‌هایی که پورتفولیوهای چند دارایی را اجرا می‌کنند که شامل جایگزین‌ها، مشتقات، اوراق بهادار با ساختارهای پیچیده و مواجهه بین‌المللی معنی‌دار هستند، از عمق تجزیه عامل که موتورهای مستقل ارائه می‌دهند، بهره‌مند می‌شوند. شرکت‌هایی که عمدتاً پورتفولیوهای مدل سهام و اوراق قرضه را اجرا می‌کنند، ممکن است متوجه شوند که ماژول‌های ریسک یکپارچه در پلتفرم‌های اولیه آنها کافی است.

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

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

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

چگونه زیرساخت عامل سفارشی شکاف‌های بین پلتفرم‌ها را پر می‌کند

شکاف‌های بین Orion، Black Diamond، Addepar و موتورهای ریسک مستقل دقیقاً جایی است که زیرساخت عامل سفارشی بیشترین اهرم را فراهم می‌کند. پلتفرم‌ها قابلیت‌های اصلی خود را به خوبی مدیریت می‌کنند؛ بافت همبند بین آنها جایی است که شرکت‌ها یا در توسعه سفارشی سرمایه‌گذاری می‌کنند یا اصطکاک عملیاتی را می‌پذیرند که در طول زمان افزایش می‌یابد.

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

TFSF Ventures FZ-LLC (RAKEZ License 47013955) این بافت همبند را برای شرکت‌های مشاوره که پشته‌های چند پلتفرمی را تحت یک روش استقرار 30 روزه اجرا می‌کنند، توسعه می‌دهد که جریان‌های داده‌ای خاص شرکت را در زیرساخت عامل که شرکت تحت یک مجوز دائمی مالک آن است، ترسیم می‌کند. این عوامل یکپارچه‌سازی، نظارت، تطبیق و مدیریت استثنا را انجام می‌دهند که در غیر این صورت به نیروی انسانی عملیاتی یا پذیرش حالت‌های شکست خاموش نیاز دارد.

سرمایه‌گذاری‌های استقرار از طریق TFSF در ده‌ها هزار دلار کم برای ساخت‌های متمرکز با تعداد اندکی از عوامل شروع می‌شود و با تعداد عوامل، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی مقیاس می‌یابد. هزینه انتقال جداگانه زیرساخت هوش مصنوعی تقریباً چهارصد تا پانصد دلار در ماه از Pulse AI با هزینه بدون سود دریافت می‌شود، و مشتری کد منبع را تحت مجوز دائمی مالک است، که وابستگی به فروشنده را که خطر انتقال را در طول تغییر رژیم یا مهاجرت پلتفرم ایجاد می‌کند، حذف می‌کند.

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

آنچه لایه مستندات رعایت مقررات باید در سراسر پلتفرم‌ها مدیریت کند

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

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

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

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

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

چگونه واقعیت چند نگهبان را در سراسر پشته مدیریت کنیم

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

روش‌شناسی مدیریت واقعیت چند نگهبان با در نظر گرفتن داده‌های نگهبان به عنوان ورودی که نیاز به نرمال‌سازی دارد، شروع می‌شود نه به عنوان وضعیت معتبر. هر نگهبان دارایی‌ها را به طور متفاوت نمایش می‌دهد، اقدامات شرکتی را پردازش می‌کند و عملکرد را گزارش می‌دهد، و دیدگاه متعارفی که شرکت به مشتریان ارائه می‌دهد، باید این تفاوت‌ها را در یک نمایش ثابت تطبیق دهد.

زیرساخت جمع‌آوری باید مکانیک عملیاتی کشیدن داده‌ها از APIهای مختلف نگهبان، نرمال‌سازی فرمت‌ها و تطبیق ناهماهنگی‌ها بین منابع را مدیریت کند. پلتفرم‌هایی مانند Orion، Black Diamond و Addepar همگی این را به درجات مختلفی مدیریت می‌کنند، و شکاف‌هایی که ظاهر می‌شوند معمولاً در نحوه مدیریت موارد استثنایی است که منطق تطبیق استاندارد نتیجه تمیزی تولید نمی‌کند.

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

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

انتساب عملکرد باید به کمیته سرمایه‌گذاری چه چیزی بگوید

تحلیل‌های انتساب عملکرد در سراسر یک پشته چند پلتفرمی باید به سؤالات خاصی پاسخ دهد که کمیته سرمایه‌گذاری در مورد اینکه چرا پورتفولیوها آنطور که عمل کردند، پرسیده خواهد شد. پلتفرم‌های مختلف انتساب را به طور متفاوتی مدیریت می‌کنند، و روش‌شناسی تولید پاسخ‌هایی که کمیته سرمایه‌گذاری به آنها اعتماد دارد، شامل تصمیم‌گیری در مورد اینکه کدام پلتفرم انتساب متعارف را ارائه می‌دهد و چگونه سایر پلتفرم‌ها به آن تغذیه می‌کنند، است.

مدل انتساب Brinson-Fachler که اکثر پلتفرم‌ها پیاده‌سازی می‌کنند، بازدهی را به اثر تخصیص، اثر انتخاب و اثر تعامل تجزیه می‌کند. سؤال روش‌شناسی این است که انتساب بر اساس کدام معیارها اجرا می‌شود، انتساب کدام ارزها را مدیریت می‌کند، و انتساب کدام مواجهه عوامل را فراتر از اجزای اصلی تخصیص و انتخاب اندازه‌گیری می‌کند.

لایه انتساب عامل که سرمایه‌گذاران سازمانی انتظار دارند، فراتر از تجزیه Brinson-Fachler به مواجهه عوامل خاص مانند ارزش، مومنتوم، کیفیت و نوسانات پایین می‌رود. شرکت‌هایی که به این عمق نیاز دارند، معمولاً آن را از طریق یک موتور ریسک مستقل مانند Aladdin اجرا می‌کنند تا اینکه به ماژول‌های انتساب اصلی در Orion، Black Diamond یا Addepar تکیه کنند.

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

چگونه معماری باید با رشد شرکت تکامل یابد

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

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

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

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

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را از طریق سه ستون یکپارچه در کسب‌وکارها مستقر می‌کند: زیرساخت عامل، ریل‌های پرداخت غیرسنتی و یک موتور سرمایه‌گذاری کامل. با 27 سال تجربه در پرداخت و نرم‌افزار، TFSF به صورت جهانی فعالیت می‌کند و با روش استقرار 30 روزه به 21 صنعت خدمات می‌دهد. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

ارزیابی هوش عملیاتی رایگان را انجام دهید. به چند سوال کوتاه در مورد کسب‌وکار خود پاسخ دهید. در عرض 24 تا 48 ساعت یک طرح استقرار هوش مصنوعی سفارشی شامل توصیه‌های عامل، معماری و یک نقشه راه خاص برای عملیات خود دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در https://tfsfventures.com/assessment

Originally published at https://tfsfventures.com/blog/architecting-ai-powered-portfolio-management-across-orion-black-diamond-addepar

Written by TFSF Ventures Research