مهندسی اتوماسیون هوش مصنوعی برای بانک‌های جامعه در سیستم‌های Jack Henry, Fiserv DNA, FIS Horizon و موتورهای انطباق مستقل

اکثر بانک‌های جامعه، استقرار هوش مصنوعی را به عنوان یک مشکل انتخاب نرم‌افزار تلقی می‌کنند. آن‌ها یک درخواست پروپوزال (RFP) صادر می‌کنند، دموهای فروشنده را مقایسه می‌کنند، یک پلتفرم را انتخاب می‌کنند، و شش ماه بعد متوجه می‌شوند که پلتفرم در واقع با سیستم بانکداری اصلی به شکلی که در دمو پیشنهاد شده بود، یکپارچه نمی‌شود. مشکل عمیق‌تر معماری است، نه تدارکات. اتوماسیون هوش مصنوعی برای بانک‌های جامعه تنها زمانی کار می‌کند که لایه عامل بر اساس واقعیت‌های هسته اصلی، موتور انطباق و ساختار یکپارچگی که همه چیز را به هم متصل می‌کند، طراحی شود، و این مشکل طراحی بسته به اینکه بانک از Jack Henry، Fiserv DNA، FIS Horizon استفاده می‌کند یا مجموعه‌ای از ابزارهای انطباق مستقل که طی دو دهه گذشته به هم متصل شده‌اند، اساساً متفاوت به نظر می‌رسد.

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

شروع با محدودیت‌های بانکداری اصلی

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

محیط‌های Jack Henry از طریق اکوسیستم JHA Open API یک سطح یکپارچگی نسبتاً مدرن را ارائه می‌دهند، به این معنی که عوامل را می‌توان برای مصرف داده‌های بلادرنگ از SilverLake، Core Director یا CIF 20/20 با تلاش مهندسی قابل مدیریت ساخت. تصمیم معماری در فروشگاه‌های Jack Henry این است که آیا عواملی ساخته شود که مستقیماً با APIهای هسته صحبت کنند یا یک لایه داده میانی معرفی شود که هسته را انتزاع می‌کند. رویکرد مستقیم سریع‌تر مستقر می‌شود اما اتصال محکم‌تری ایجاد می‌کند. رویکرد انتزاعی زمان بیشتری می‌برد اما به‌روزرسانی‌های هسته را با ظرافت بیشتری تحمل می‌کند.

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

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

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

طراحی ساختار یکپارچگی

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

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

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

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

سوال چهارم طراحی، قابلیت مشاهده (observability) است. ساختار پیچیده‌ترین لایه از نظر عملیاتی در معماری است، و بدون قابلیت مشاهده قوی، بانک نمی‌تواند در صورت بروز مشکلات، آن‌ها را تشخیص دهد. قوی‌ترین معماری‌ها قابلیت مشاهده را به عنوان یک نیاز طراحی کلاس اول در نظر می‌گیرند، با ثبت ساختاریافته (structured logging)، ردیابی توزیع‌شده (distributed tracing)، و معیارهایی که به تیم عملیات اجازه می‌دهند دقیقاً ببینند که یک جریان کاری در کجا متوقف شده است. بانک‌هایی که از قابلیت مشاهده چشم پوشی می‌کنند، معمولاً مشکلات تولیدی را تنها پس از اینکه مشتری یا بازرس آن‌ها را مطرح می‌کند، کشف می‌کنند.

معماری لایه عامل

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

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

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

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

هم‌راستایی با الگوهای انطباق و بازرسی

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

اولین ملاحظه انطباق، مدیریت ریسک مدل است. بازرسان SR 11-7 و OCC 2011-12 را برای مدل‌های هوش مصنوعی اعمال می‌کنند، به این معنی که بانک به تأیید مدل مستند شده، نظارت مداوم و مالکیت واضح ریسک مدل نیاز دارد. قوی‌ترین معماری‌ها مستندات مدل، شواهد تأیید و معیارهای نظارت را مستقیماً در زیرساخت عامل جاسازی می‌کنند، بنابراین تیم انطباق می‌تواند مستندات مورد درخواست بازرسان را بدون مونتاژ دستی تولید کند.

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

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

چهارمین ملاحظه انطباق، حمایت از مصرف‌کننده است. هر هوش مصنوعی مورد استفاده در کانال‌های رو به مشتری باید با UDAAP، Reg E، Reg Z و مجموعه کامل مقررات حمایت از مصرف‌کننده مطابقت داشته باشد. قوی‌ترین معماری‌ها بررسی انطباق را در طراحی عامل جاسازی می‌کنند تا اینکه به عامل تکیه کنند که قوانین را بداند، به این معنی که تیم انطباق خروجی‌های عامل را قبل از رسیدن به مشتریان تأیید می‌کند.

چرا شریک استقرار مهم‌تر از پلتفرم است

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

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

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

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

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

توالی‌بندی استقرار

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

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

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

آنچه در هر معماری ثابت می‌ماند

در محیط‌های Jack Henry, Fiserv DNA, FIS Horizon و انطباق مستقل، اصول معماری خاصی ثابت می‌مانند. هسته یک محدودیت است نه یک هدف. ساختار یکپارچگی به مدیریت خرابی صریح و قابلیت مشاهده نیاز دارد. لایه عامل به تفکیک واضح جریان‌های کاری و مدیریت استثنائات صریح نیاز دارد. ملاحظات انطباق باید از اولین تصمیم طراحی جاسازی شوند. شریک استقرار مهم‌تر از پلتفرم است.

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

ملاحظات عملیاتی پس از معماری

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

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

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

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

اندازه‌گیری اثربخشی معماری

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

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

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

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

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

درباره TFSF Ventures

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

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

Originally published at https://tfsfventures.com/blog/architecting-ai-automation-for-community-banks-across-jack-henry-fiserv-dna-fis

نوشته شده توسط TFSF Ventures Research