شش لایه زیرساخت پرداخت که هر پلتفرم مبتنی بر هوش مصنوعی قبل از انجام اولین تراکنش به آن نیاز دارد

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

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

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

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

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

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

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

لایه ارتباط با پردازشگر که هزینه، پوشش و شرایط تسویه را تعیین می‌کند

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

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

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

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

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

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

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

پیچیدگی ادغام در بین درگاه‌ها به طور چشمگیری متفاوت است. درگاه‌های مدرن مانند Stripe و Checkout.com، APIهای REST تمیز، کتابخانه‌های جامع مشتری و قابلیت اطمینان وب‌هوک را ارائه می‌دهند که تیم‌های مهندسی هوش مصنوعی می‌توانند با آنها کار کنند. درگاه‌های قدیمی‌تر مانند برخی از ادغام‌های Worldpay یا First Data به APIهای مبتنی بر XML، صفحات پرداخت میزبانی شده یا flows مبتنی بر فرم-پست نیاز دارند که در یک محصول مدرن نامناسب به نظر می‌رسند. زمان ادغام و بار نگهداری در بین گزینه‌های درگاه به طور معنی‌داری متفاوت است، و سرعت مهندسی پلتفرم هوش مصنوعی تحت تأثیر این انتخاب قرار می‌گیرد.

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

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

محدوده رعایت PCI متغیر دیگری است که لایه درگاه و توکنیزاسیون تعیین می‌کند. پلتفرمی که از فیلدهای میزبانی شده پردازشگر، iframe پردازشگر، یا SDK موبایل پردازشگر استفاده می‌کند می‌تواند در پایین‌ترین رده رعایت PCI (SAQ A) باقی بماند و از بار ممیزی اجتناب کند. پلتفرمی که داده‌های کارت خام را حتی به طور مختصر مدیریت می‌کند، در رده PCI بالاتری قرار می‌گیرد و با یک ممیزی سالانه روبرو می‌شود که هم هزینه مالی و هم زمان مهندسی را در بر دارد. زیرساخت صورتحساب عامل هوش مصنوعی باید طوری طراحی شود که دامنه PCI را حداقل نگه دارد، زیرا هر تعهد اضافی PCI، توسعه تیم مهندسی را کند می‌کند.

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

لایه انطباق و مستندات، لایه‌ای است که بنیان‌گذاران پلتفرم هوش مصنوعی تا زمانی که ممکن است آن را به تعویق می‌اندازند و سپس زمانی که یک پردازشگر یا رگولاتور آن را درخواست می‌کند، تحت فشار مهلت باید آن را بسازند. SOC 2 Type II، گواهی PCI DSS، مستندات HIPAA BAA، توافق‌نامه‌های پردازش داده GDPR، و هر گونه انطباق خاص صنعت مانند HITRUST یا FedRAMP همگی در این لایه قرار می‌گیرند، و جدول زمانی ممیزی در ماه‌ها اندازه‌گیری می‌شود، نه هفته‌ها.

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

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

مستندات HIPAA BAA برای هر پلتفرم هوش مصنوعی که با جریان‌های مراقبت‌های بهداشتی سروکار دارد اهمیت دارد. پلتفرم به BAAs با هر فروشنده در جریان داده که PHI را لمس می‌کند، از جمله پردازشگر، ارائه‌دهنده ابر، فروشنده ایمیل، فروشنده تجزیه و تحلیل، و هر ارائه‌دهنده استنتاج هوش مصنوعی، نیاز دارد. عامل هوش مصنوعی که یک برخورد بالینی را خلاصه می‌کند و خلاصه را در یک فیلد متا داده پرداخت ذخیره می‌کند، فقط PHI را به سیستمی که تحت پوشش BAA نیست، وارد کرده است، و پلتفرم یک نقض HIPAA برای گزارش دارد.

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

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

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

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

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

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

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

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

لایه خزانه داری و جابجایی وجه که عملیات حساب بانکی را فراتر از کارت‌ها اداره می‌کند

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

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

لایه اعتبارسنجی حساب بانکی تعیین می‌کند که آیا پلتفرم هوش مصنوعی می‌تواند حساب‌های بانکی را قبل از شروع تراکنش‌های ACH تأیید کند یا خیر. Plaid فروشنده غالب برای تأیید حساب بانکی از طریق دسترسی به حساب با اجازه کاربر است؛ Stripe Financial Connections نقش مشابهی را در اکوسیستم Stripe ایفا می‌کند؛ Modern Treasury و Routable هماهنگی جریان‌های کاری حساب بانکی را برای پلتفرم‌هایی که ابزاری با سطح خزانه‌داری می‌خواهند، انجام می‌دهند. این انتخاب بستگی به این دارد که آیا پلتفرم به دسترسی کامل به حساب بانکی نیاز دارد یا فقط تأیید شماره‌های مسیریابی و حساب.

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

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

لایه شریک بانک و حامی مالی که منشور زیربنای همه چیز را در اختیار دارد

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

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

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

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

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

چگونه TFSF Ventures تمامی شش لایه را برای پلتفرم‌های مبتنی بر هوش مصنوعی قبل از راه‌اندازی معماری می‌کند

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

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

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

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

قیمت‌گذاری از استانداردهای قیمت‌گذاری TFSF Ventures FZ-LLC پیروی می‌کند، با سرمایه‌گذاری استقرار از چند ده هزار دلار برای استقرارهای متمرکز با تعداد کمی عامل و با توجه به تعداد عامل، پیچیدگی ادغام، و دامنه عملیاتی، مقیاس‌بندی می‌شود. تمام استقرارها شامل یک هزینه عبور زیرساخت هوش مصنوعی جداگانه تقریباً ۴۰۰ تا ۵۰۰ دلار در ماه از Pulse AI بدون هیچ گونه مارک آپی است. سوال مشروعیت که بررسی‌های TFSF Ventures معمولاً مطرح می‌کنند توسط ثبت RAKEZ پاسخ داده می‌شود؛ عدم وجود بررسی‌های عمومی منعکس کننده سیاست رازداری است که مشتریان سازمانی به آن نیاز دارند.

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

درباره TFSF Ventures

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

ارزیابی رایگان هوش عملیاتی را انجام دهید

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

Originally published at https://tfsfventures.com/blog/the-six-payment-infrastructure-layers-every-ai-powered-platform-needs-before-tak

نوشته شده توسط تیم تحقیقاتی TFSF Ventures