اگر چیزی درباره هوش مصنوعی، و به ویژه عامل‌های هوش مصنوعی بدانید، ممکن است عنوان این پست را خوانده باشید و فکر کنید «بله، البته که می‌تواند. موارد استفاده برای هوش مصنوعی و عامل‌های هوش مصنوعی در زمینه خدمات مالی به طور کلی قابل توجه است، با عامل‌هایی که قابلیت اتوماسیون وظایف متعددی را که در حال حاضر توسط انسان‌ها انجام می‌شود، دارند. این موضوع در هیچ جایی بیشتر از Open Finance صادق نیست، جایی که مدل‌های عملیاتی تقریباً کاملاً بر اساس APIهای استانداردشده توصیف‌شده با استفاده از OpenAPI ساخته شده‌اند، که پایه قوی برای تفسیر توسط هوش مصنوعی فراهم می‌کند. موارد استفاده موجود فراوان هستند، با پتانسیل هوش مصنوعی برای کار در سراسر مالی بسته و باز برای ایجاد ویژگی‌ها و محصولات منسجم.
برخی از موارد استفاده ممکن برای عامل‌های هوش مصنوعی در Open Finance شامل:
- آغاز پرداخت: انجام یک یا چند پرداخت به طور خودکار، به نمایندگی از مشتری بانکی، بر اساس محدودیت‌های ثابت تعریف‌شده در رضایت.
- جاروب حساب: انتقال خودکار وجوه از حساب‌های جاری و چک به حساب‌های پس‌انداز برای حداکثر کردن بازده.
- مدیریت ثروت: ایجاد دید منسجم از ثروت در حساب‌ها و وسایل سرمایه‌گذاری مختلف، با بهره‌برداری از ویژگی‌هایی مانند جاروب حساب برای حداکثر کردن نتایج.
اگر Open Finance امروز از صفر ساخته می‌شد، پیاده‌سازی پروتکل‌های امنیتی و الگوهای لازم برای اجازه دسترسی عامل هوش مصنوعی، گسترش طبیعی به استانداردها می‌بود. با این حال، زندگی هرگز اینقدر ساده نیست. Open Finance به طور جهانی در حال رشد است، با نوآوری‌های زیادی که رخ می‌دهد. همچنان، پروتکل‌های امنیتی و الگوها عمدتاً به مکانیسم‌های تثبیت‌شده مانند OAuth 2.0، OpenID Connect، و اکستنشن‌های آن پروتکل‌ها مانند FAPI 2.0 Security Profile وابسته هستند. این پروتکل‌ها عموماً شامل انسانی در جریان در نقطه‌ای هستند، به ویژه با توجه به قوانینی مانند الزام در اتحادیه اروپا برای مجوز مجدد دسترسی به حساب هر ۱۸۰ روز. تکامل این پروتکل‌ها برای تناسب با مدل عامل‌محور حیاتی برای اطمینان از از دست نرفتن فرصت هوش مصنوعی در Open Finance است.
مورد استفاده برای هوش مصنوعی در Open Finance
استقرار هوش مصنوعی در Open Finance، به ویژه از دیدگاه عامل‌محور، در واقع پیشرفت طبیعی آنچه ارائه‌دهندگان شخص ثالث (TPPها) قبلاً در اکوسیستم مالی انجام می‌دهند، است. جاروب حساب را به عنوان مثال بگیرید. جاروب کاملاً با مدل عامل‌محور تناسب دارد، زیرا عامل‌ها می‌توانند به نمایندگی از انسان‌ها برای انجام جاروب به طور خودکار بر اساس مجموعه شناخته‌شده محدودیت‌های کدگذاری‌شده در رضایت اعطا‌شده توسط انسان به TPP یا به عامل هوش مصنوعی کار کنند.
تکامل Open Finance در بازارهای جهانی، با این حال، فرصت‌های عامل‌محور جدیدی به طور کلی ارائه می‌دهد. مقایسه نرخ ارز خارجی (FX) باز را در نظر بگیرید، که در حال حاضر در امارات متحده عربی ایجاد می‌شود، که مقایسه نرخ FX در سراسر بازار را امکان‌پذیر می‌کند، پشتیبانی‌شده توسط افتتاح حساب پویا در ارائه‌دهنده FX داده‌شده. فعال‌سازی عامل‌های هوش مصنوعی برای بهره‌برداری از این چارچوب می‌تواند مزایای مالی قابل توجهی برای سازمان‌هایی که به دنبال کاهش هزینه‌های FX و حواله و ترویج رقابت جدید در بازار FX محلی هستند، فراهم کند. جریان‌های FX و حواله نسبتاً ساده هستند و برای عامل ساده است که روی آنها عمل کند.
بزرگ‌ترین چالش، با این حال، در تقاطع خودمختاری و اعتماد نهفته است، و اینکه عامل‌ها چگونه می‌توانند بدون انسانی در جریان عمل کنند.
فراخوانی‌های جانبی به انسان‌ها
اپن فایننس (Open Finance) قبلاً زمینه‌ای برای برقراری خودمختاری با اعطای دسترسی TPPها به حساب‌های مشتری به موجودیت‌هایی که بانک نیستند، شکسته است. با این حال، چارچوب‌های بانکداری باز و Open Finance با انسان‌ها در مرکز سفر رضایت ساخته شده‌اند. احراز هویت قوی مشتری (SCA) و قوانینی مانند مجوز مجدد ۱۸۰ روزه PSD2 نیازمند انسانی برای تأیید مجدد انتخاب‌هایشان هستند، و اصطکاک عمدی برای اطمینان از اینکه مشتریان نگهدارنده حساب که رضایت به دسترسی حساب می‌دهند، با آگاهی کامل از اقداماتی که انجام می‌دهند، اضافه می‌کنند. FAPI 2.0، مورد استفاده در بسیاری از اکوسیستم‌های Open Finance پیشرو در سراسر جهان، و چارچوب‌های کمتر تجویزی دیگر مانند چارچوب امنیتی در قلب گروه برلین، این مفهوم دسترسی رضایت‌شده و مجاز را در قلب خود دارند.
افزودن اصطکاک به این روش به تلاشهای کاربر به خوبی برای اعطای مجوزها به عامل‌های هوش مصنوعی برای عمل خودمختار وام نمی‌دهد. انسانی همچنان باید به سفر فراخوانی شود وقتی مجوز مجدد حساب لازم است. چالش دیگری مدیریت چرخه حیات توکن است. پروفایل‌های OAuth فعلی، به طور کلی، برای actors کاملاً خودمختار بلندمدت طراحی نشده‌اند، و نیاز به «فراخوانی مجدد» به انسان‌ها به طور ضمنی در جریان است. توکن‌های دسترسی اعطا‌شده توسط کاربر جایی است که پروتکل‌هایی مانند پروتکل زمینه مدل (MCP) در حال حاضر گیر می‌کنند. یک سرور MCP می‌تواند OAuth 2.0 را پیاده‌سازی کند، بدون مشکل. با این حال، انجام این کار تحت نوع اعطای جریان کد مجوز کمتر امکان‌پذیر است.
با این حال، فرصت‌های قابل توجهی برای فعال‌سازی دسترسی عامل‌محور، با فراخوانی‌های جانبی به انسان‌ها، بدون بازسازی اکوسیستم و پروتکل‌های زیرین وجود دارد. پذیرش تکامل احراز هویت و مجوز جایی که مجوز مجدد می‌تواند seamless رخ دهد، حیاتی است. در Open Finance، می‌توانیم پروتکل‌هایی مانند OpenID for Verifiable Credentials را فراخوانی کنیم، که قبلاً ویژگی کیف پول دیجیتال اتحادیه اروپا است، که می‌تواند backbone برای اعتبارهای اختصاصی و مجاز برای عامل‌ها فراهم کند، یا بهره‌برداری از Client-Initiated Backchannel Authentication (CIBA) برای اجازه احراز هویت و مجوز خارج از باند توسط انسانی. بلوک‌های ساختمانی حیاتی برای مجوز دسترسی عامل‌محور رضایت‌شده به حساب‌ها بنابراین قبلاً وجود دارند، و می‌توانند گسترش یابند تا اطمینان حاصل شود فراخوانی‌های مجدد به انسان‌ها، وقتی لازم هستند، می‌توانند seamless رخ دهند.
حل برای Open Finance خودمختار
سفر احراز هویت و فعال‌سازی فراخوانی‌های جانبی سیستماتیک به انسان‌ها یک سمت سکه عامل‌محور در Open Finance است. ارائه اعطاهای صریح به دسترسی حساب حیاتی برای اجازه دسترسی عامل‌محور به حساب‌ها است. همانطور که اغلب با فناوری‌های جدید رخ می‌دهد، جامعه هوش مصنوعی پیش رفته با توسعه پروتکل‌های جدید که نیازهای عامل‌ها در عمل به نمایندگی از انسان‌ها را خدمت‌رسانی می‌کنند.
ابتکاراتی مانند پروتکل Agent2Agent (A2A) و پروتکل پرداخت‌های عامل‌محور هدف اجازه عامل‌ها برای عمل خودمختار بدون تکیه به انسان‌ها در جریان، با استفاده از سری «Mandates» که به عنوان اعتبارهای قابل تأیید عمل می‌کنند، وابسته به عامل و اقدام خاص. پروتکل تجارت عامل‌محور، توسعه‌یافته توسط OpenAI و Stripe، همچنین به دنبال قدرت دادن به پرداخت‌های انجام‌شده خودمختار به نمایندگی از مشتریان از طریق عامل هوش مصنوعی اختصاصی است.
در حالی که این پروتکل‌ها مطلقاً لازم برای ارائه چارچوب مشترک برای ارتباط و اقدام عامل‌محور هستند، مفاهیم زیرین فعال‌سازی نقش‌ها در اکوسیستم برای انجام وظایف خاص قبلاً در جهان Open Finance تثبیت‌شده هستند.
مثالی اینجا درخواست‌های مجوز غنی (RAR) است، که قبلاً در چندین اکوسیستم، شامل امارات متحده عربی، استفاده می‌شود. RAR وسیله‌ای به طور قابل توجه بهبودیافته برای توصیف حقوق دسترسی حساب و خدمات به روشی دقیق فراهم می‌کند، و مجوزهای دقیق کلاینت را مشخص می‌کند. RAR تکامل APIهای رضایت ایجادشده در موج اول استانداردهای بانکداری باز است، و مدل permissioning را به قلمرو کنترل‌های دسترسی باز می‌گرداند. چیز عالی درباره RAR این است که، از دیدگاه پروتکل، آنچه یک scope OAuth نشان می‌دهد را به طور قابل توجه گسترش می‌دهد و آن را بسیار صریح‌تر می‌کند.
RAR همچنین یک چارچوب است، و می‌تواند گسترش یابد تا prompts را همراه با داده‌های ساختاریافته بگنجاند. بنابراین یک RAR می‌تواند منبع حقیقت واحد برای عامل شود، و تکامل یابد تا دید عامل‌محورتری با prompt زبان طبیعی فراهم کند. مثالی در زیر (کدگذاری‌شده به عنوان YAML برای خوانایی، اما احتمالاً JSON):
roles:
- aisp
- pisp
use_case: account_sweeping
source_accounts:
- current
target_accounts:
- savings
- stocks_shares_isa
prompt: >
Use my balance and transaction information from my current and savings account to track outgoings.
Move money from my current account when the account balance exceeds GBP 5000, moving to my savings account with the best interest rate.
When my balance across my current account and savings exceeds my outgoings for the next 3 months, move any surplus to my stocks and shares ISA.RAR بنابراین می‌تواند تمام الزامات برای عامل‌ها را شامل شود، شامل اینکه چه نقش‌هایی می‌توانند بازی کنند، که سپس اجازه می‌دهد عامل‌ها با داده‌های مرجع مانند OpenID Connect Discovery برای هدایت اقدامات‌شان تعامل کنند.
سطح استانداردسازی در RAR همچنان نیاز به بالا بودن دارد، با این حال، برای اطمینان از اینکه هم TPPها و هم بانک‌ها می‌توانند RAR را به روشی قطعی اعمال کنند، و ممکن است کاملاً با انتقال تمام جزئیات رضایت به prompt برآورده نشود. مثال بالا، اگر در طراحی RAR واقعی منعکس شود، تقریباً مطمئناً داده‌های ساختاریافته بیشتری شامل می‌شود، با رفتارهای بیشتری که در خواص تعریف‌شده خوب یک سند JSON Schema یا توصیف OpenAPI کدگذاری شده‌اند. RAR همچنین نیاز به امضا شدن برای اطمینان از ضد نفوذ بودن دارد، بنابراین باید با استفاده از JWT-Secured Authorization Requests پیاده‌سازی شود و از طریق کانالهای پشتی با استفاده از Pushed Authorization Requests ارسال شود تا درخواست در انتقال حفاظت شود و از redirects اجتناب شود.
RAR همچنین می‌تواند به معنای تسریع پیاده‌سازی Open Finance باشد، با تغییر که راحت‌تر پذیرفته می‌شود. برای انسان‌ها، RAR به معنای پیاده‌سازی نرم‌افزار پیچیده‌تر و پیچیده‌تر برای تفسیر این اطلاعات به روشی معنادار بوده است. برای عامل‌های هوش مصنوعی، با این حال، می‌تواند به معنای گرفتن اطلاعات و عمل روی آن بدون نیاز به انسان‌ها برای نوشتن توده‌های کد باشد. بله، عامل یا هوش مصنوعی کد را جایی spool خواهد کرد، برای مقابله با تفسیر اطلاعات، اما آن اطلاعات می‌تواند بسیار راحت‌تر پردازش شود، و علاوه بر این، اطلاعات در RAR می‌تواند با نسخه‌های جدید استانداردها پیاده‌سازی پایین‌تر تکامل یابد، زیرا هوش مصنوعی با تغییرات مقابله خواهد کرد.
امنیت API برای آینده‌های هوش مصنوعی
ما جنبه‌های زیادی از Open Finance و چگونگی ادغام هوش مصنوعی در استانداردهای امنیت API موجود را بحث کردیم. مدلی از آنچه بحث کردیم، جایی که OpenID Discovery، PAR، JAR، RAR، و CIBA را در یک توالی وب گرد هم می‌آوریم، در زیر نشان داده شده است. این عمداً MCP و چگونگی مدیریت کنترل در سرورهای MCP را نادیده می‌گیرد و همچنین از الگوهای ضد token passthru اجتناب می‌کند، زیرا آن موضوع برای پست دیگری است.
اسکلت از پرداخت‌های تکراری متغیر بهره می‌برد، که در بازارهایی مانند بریتانیا و امارات متحده عربی پیاده‌سازی شده‌اند. توجه کنید اینجا، ما پروتکل عامل یا چگونگی آغاز عامل را بیان نمی‌کنیم، فقط اینکه عامل promptی برای عمل به نمایندگی از مشتری دریافت می‌کند.
استفاده از محافظ (Guardrails) برای مالی عامل‌محور
پذیرش هوش مصنوعی، در بررسی این پست، ممکن است به عنوان گام بعدی در تکامل Open Finance به نظر برسد، و بلوک‌های ساختمانی زیادی قبلاً در جای خود هستند که می‌توانند بهره‌برداری شوند. همچنین، البته، راه طولانی بین ترسیم جریان‌ها در دیاگرام توالی و استقرار این جریان در خشم است. صنعت به طور کلی نیاز به اطمینان از اینکه محافظ درست در جای خود هستند برای حفاظت از چگونگی اعطای توکن دسترسی به عامل هوش مصنوعی دارد.
سؤال مقیاس‌پذیری اعتبارها نیز وجود دارد تا اطمینان حاصل شود عامل‌ها دسترسی آماده به پلتفرم‌های Open Finance دارند. MCP می‌تواند بالقوه کمک کند، و می‌تواند در مدل سطح بالا نشان‌داده‌شده بالا جای گیرد (دوباره، موضوعی برای پست آینده). در نهایت، نقطه‌ای درباره بلوغ Open Finance در بازارهای مختلف نیز وجود دارد. چندین بازار اکثر، اما نه همه، این بلوک‌های ساختمانی را در جای خود دارند، و پیشبرد بازار نیازمند همترازی مقرراتی، تقاضا از بازار، و پیاده‌سازی در بانک‌ها است.
از دیدگاه حفاظت از انسان‌های واقعی و مالی‌شان، درست و خوب است که این سؤالات را بپرسیم. ما در رشد هوش مصنوعی دیده‌ایم که چگونه می‌تواند، و ادامه می‌دهد، اشتباه کند. با این حال، عامل‌ها می‌توانند موارد استفاده مانند جاروب حساب را در سطح بسیار دقیق‌تری قدرت دهند، و با ابزارهای درست در جای خود، Open Finance می‌تواند پذیرش این کار را به طور امن، و با نیازهای مشتریان در قلبش، بپذیرد.
پذیرش هوش مصنوعی درباره کاهش امنیت یا مجازتر کردن دسترسی عامل‌محور به حساب‌ها نیست. در عوض، درباره اطمینان از اینکه محافظ در ارتفاع درست تنظیم شده‌اند، و با نرده‌های کافی پایدار برای هدایت هوش مصنوعی به دقیقاً آنچه نیاز به دانستن برای عمل در بهترین منافع مشتری دارد.
تکامل بازارها و استانداردهای Open Finance نیاز به پذیرش تغییر برای هوش مصنوعی در سه راه حیاتی دارد:
- مجوز frictionless: واگذاری اختیار به هوش مصنوعی، به همان روش اعطای رضایت به دسترسی حساب برای TPP، نیاز به رخ دادن بسیار آسان‌تر دارد، و حذف redirects به اپ بانکداری موبایل یا وبسایت بانکداری اینترنتی در سفرهای موجود. سفرهایی که امروز در Open Finance وجود دارند می‌توانند کشیده شوند تا اثبات احراز هویت و مجوز قطعی، قابل اعتماد، و cryptographically bound را پروفایل کنند که فراتر از شک معقول ثابت کنند مشتری رضایت ارائه کرده است.
- کنترل‌های دسترسی عامل‌محور: بهبود مرزهای مجوز از طریق اعطاهای بسیار توصیفی اساسی برای برقراری محافظ درست است. پذیرش RAR و ارائه مجوز که دقیق و قطعی است بهترین شانس برای عامل‌های هوش مصنوعی برای عمل خودمختار بدون پتانسیل از دست دادن داده یا مالی برای مشتریان بانکی ارائه می‌دهد.
- نظارت مداوم و مداوم: نظارت بر فعالیت‌های عامل‌های هوش مصنوعی حیاتی برای اعتماد مداوم است، و اینجا Open Finance می‌تواند از پروتکل‌های مجاور مانند OpenID Shared Signals بهره ببرد، که پروتکل ارزیابی دسترسی مداوم را به عنوان وسیله‌ای برای نظارت بر عامل‌ها در مقیاس از طریق پروتکل‌های مشترک، در سراسر اکوسیستم، فراهم می‌کند، و دید مشتری واحد ارائه می‌دهد.
اگر بازارهای Open Finance جهانی بتوانند چنین تحولاتی را بپذیرند و پروتکل‌های مناسب و right-sized برای ایمن‌سازی داده‌های مشتری در حالی که عامل‌های هوش مصنوعی را قدرتمند می‌کنند، طراحی کنند، Open Finance می‌تواند به عنوان رهبر در سطح صنعت پیش برود. زمان خواهد گفت آیا انسان‌های مهم در Open Finance — مقررات‌گذاران، بانک‌ها، بدنه‌های استاندارد، و TPPها — این فرصت قابل توجه برای رهبری Open Finance خودمختار را خواهند گرفت.
