بانک‌ها معمولاً مجموعه‌ای از سامانه‌های عملیاتی دارند که در دوره‌های مختلف و با فناوری‌های متفاوت توسعه یافته‌اند. هسته بانکی (Core Banking)، سامانه‌های کارت و پرداخت، تسهیلات، سپرده، خزانه‌داری و سامانه‌های مدیریت مشتری هرکدام بخشی از عملیات بانک را پوشش می‌دهند. این سامانه‌ها ممکن است سال‌ها بدون اختلال جدی فعالیت کرده باشند، اما لزوماً برای تبادل یکپارچه اطلاعات و پاسخ‌گویی به نیازهای تحلیلی امروز طراحی نشده‌اند.
نتیجه این وضعیت، پراکندگی داده‌ها، گزارش‌های متفاوت میان واحدها، دشواری دسترسی به اطلاعات به‌روز و وابستگی به فرایندهای دستی برای تهیه گزارش‌های مدیریتی است.
در چنین شرایطی، راهکار الزاماً تعویض کامل سیستم‌های قدیمی نیست. یکپارچه‌سازی سیستم‌های بانکی Legacy به معنای ایجاد ارتباط کنترل‌شده میان سامانه‌های موجود و زیرساخت داده مدرن است؛ به‌گونه‌ای که بانک بتواند بدون ایجاد اختلال در عملیات روزمره، از اطلاعات پراکنده برای گزارش‌گیری، تحلیل و تصمیم‌گیری استفاده کند.
چرا یکپارچه‌سازی سیستم‌های بانکی قدیمی دشوار است؟
سامانه‌های بانکی قدیمی معمولاً برای پاسخ‌گویی به نیازهای مشخص عملیاتی ساخته شده‌اند. بخشی از منطق کسب‌وکار ممکن است در ساختار پایگاه داده، رویه‌های ذخیره‌شده یا برنامه‌های اختصاصی پیاده‌سازی شده باشد. همچنین، سامانه‌های مختلف ممکن است از فناوری‌ها، قالب‌های اطلاعاتی و شناسه‌های متفاوت استفاده کنند.
۱. پراکندگی منابع اطلاعاتی: اطلاعات یک مشتری ممکن است در سامانه سپرده، تسهیلات، کارت و سامانه ارتباط با مشتری نگهداری شود. بدون یکپارچه‌سازی، دستیابی به نمای کامل مشتری دشوار خواهد بود.
۲. تفاوت در ساختار و تعریف داده‌ها: یک شناسه مشتری یا کد شعبه ممکن است در سامانه‌های مختلف با قالب متفاوت ثبت شده باشد. حتی تعریف شاخص‌هایی مانند مانده حساب یا مشتری فعال می‌تواند میان واحدها متفاوت باشد.
۳. محدودیت دسترسی به سامانه‌های قدیمی: تغییر کد یا ساختار هسته بانکی معمولاً به دلیل حساسیت عملیات، پیچیدگی فنی و نیاز به آزمون‌های گسترده با محدودیت همراه است.
۴. تداخل پردازش تحلیلی با عملیات بانکی: اجرای پرس‌وجوهای سنگین روی پایگاه داده عملیاتی می‌تواند منابع پردازشی موردنیاز ثبت تراکنش‌ها را مصرف کند.
به همین دلیل، معماری یکپارچه‌سازی باید ضمن حفظ پایداری منابع عملیاتی، امکان انتقال و استفاده مجدد از داده‌ها را فراهم کند.
روش‌های اتصال سامانه‌های Legacy بانکی
برای اتصال سیستم‌های قدیمی به زیرساخت مدرن، یک روش واحد برای تمام منابع وجود ندارد. انتخاب فناوری به نوع سامانه، امکانات اتصال، حجم اطلاعات، حساسیت داده و میزان تازگی موردنیاز بستگی دارد.
۱. انتقال دسته‌ای داده (Batch Integration)
در روش Batch، اطلاعات در بازه‌های زمانی مشخص از منابع استخراج و به مقصد منتقل می‌شوند. این بازه می‌تواند روزانه، ساعتی یا متناسب با نیاز عملیاتی بانک تنظیم شود.
این روش برای اطلاعات تاریخی، گزارش‌های دوره‌ای و سامانه‌هایی که امکان ارائه جریان تغییرات ندارند، کاربرد دارد. همچنین می‌توان با استفاده از فایل‌های استاندارد یا رابط‌های تبادل اطلاعات، سامانه‌های قدیمی را به بستر یکپارچه‌سازی متصل کرد.
محدودیت اصلی این روش، فاصله زمانی میان ثبت اطلاعات در مبدأ و دسترسی به آن در مقصد است.
۲. دریافت تغییرات با CDC
فناوری Change Data Capture یا CDC امکان شناسایی و انتقال تغییرات پایگاه داده را فراهم می‌کند. در روش لاگ‌محور، به‌جای خواندن مداوم جداول، تغییرات از لاگ تراکنش پایگاه داده دریافت می‌شوند.
این رویکرد برای بانک‌هایی که به انتقال مکرر اطلاعات از هسته عملیاتی نیاز دارند، قابل بررسی است. برای مثال، تغییرات اطلاعات حساب یا وضعیت تسهیلات می‌تواند به یک بستر تحلیلی منتقل شود، بدون اینکه گزارش‌های تحلیلی مستقیماً روی پایگاه داده اصلی اجرا شوند.
در بانک‌هایی که از Oracle استفاده می‌کنند، امکان بررسی ابزارهایی مانند Debezium و سازوکار LogMiner وجود دارد. البته انتخاب این روش به نسخه پایگاه داده، تنظیمات Archivelog و Supplemental Logging، ظرفیت لاگ‌ها و الزامات عملیاتی وابسته است. برای مثال، فعال‌سازی Supplemental Logging در سطح ستون‌ها می‌تواند حجم Redo Log را افزایش دهد؛ بنابراین تنظیمات باید با مشارکت تیم DBA انجام شود.
CDC زمانی ارزشمند است که انتقال مکرر تغییرات برای بانک اهمیت داشته باشد؛ اما برای تمام جداول و همه سامانه‌ها ضرورت ندارد.
۳. یکپارچه‌سازی از طریق API و سرویس‌های واسط
برخی سامانه‌های بانکی از رابط‌های برنامه‌نویسی (API) یا سرویس‌های وب برای تبادل اطلاعات پشتیبانی می‌کنند. در این شرایط، یک لایه واسط می‌تواند درخواست‌ها را دریافت، اعتبارسنجی و به سامانه مقصد هدایت کند.
این روش به‌ویژه برای اتصال اپلیکیشن‌های بانکی، سامانه‌های خدمات دیجیتال، سرویس‌های مشتریان و سامانه‌های بیرونی کاربرد دارد.
نکته مهم این است که API و CDC کارکرد یکسانی ندارند. API برای تبادل درخواست و پاسخ یا ارائه قابلیت‌های عملیاتی مناسب است؛ درحالی‌که CDC برای دریافت تغییرات داده و انتقال آن‌ها به مقصد استفاده می‌شود.
در یک معماری سازمانی ممکن است هر دو روش به‌صورت مکمل به کار گرفته شوند.
معماری پیشنهادی برای یکپارچه‌سازی داده‌های بانکی
معماری مناسب باید بتواند داده‌های چند سامانه مستقل را دریافت، استانداردسازی و برای استفاده در گزارش‌ها و تحلیل‌های سازمانی آماده کند.
یک الگوی عمومی برای این معماری شامل اجزای زیر است:
۱. منابع عملیاتی: هسته بانکی، سامانه کارت، پرداخت، سپرده، تسهیلات، خزانه‌داری و سامانه‌های جانبی.
۲. لایه اتصال و دریافت: مجموعه‌ای از کانکتورها، سرویس‌های واسط، فرایندهای Batch و ابزارهای CDC که داده‌ها را از منابع دریافت می‌کنند.
۳. ناحیه Staging: داده‌های دریافتی در این ناحیه نگهداری می‌شوند تا امکان کنترل، ردیابی و پردازش مجدد اطلاعات وجود داشته باشد.
۴. استانداردسازی و یکپارچه‌سازی: قالب تاریخ‌ها، شناسه مشتریان، کد شعب، واحدهای پولی و سایر فیلدهای مشترک با قواعد مشخص یکسان‌سازی می‌شوند.
۵. بستر ذخیره‌سازی تحلیلی: داده‌های آماده‌شده در انبار داده سازمانی (EDW) یا ساختارهای تحلیلی متناسب ذخیره می‌شوند تا امکان بررسی تاریخی و تحلیل بین‌سامانه‌ای فراهم شود.
۶. لایه مصرف و تحلیل: داشبوردهای مدیریتی، گزارش‌های نظارتی، سامانه‌های هوش تجاری و ابزارهای تحلیل داده از اطلاعات یکپارچه استفاده می‌کنند.
در این معماری، هسته بانکی همچنان مرجع ثبت عملیات باقی می‌ماند و زیرساخت تحلیلی مسئول نگهداری و پردازش داده برای مصارف مدیریتی و تحلیلی است.
همینطور بخوانید: معماری انبار داده سازمانی (EDW): از Staging تا Semantic Layer
ملاحظات امنیتی و اجرایی در بانک‌های ایرانی
یکپارچه‌سازی داده‌های بانکی صرفاً مسئله انتقال اطلاعات نیست. حساسیت داده‌های مالی و الزامات پایداری خدمات باعث می‌شود طراحی این معماری به ملاحظات بیشتری نیاز داشته باشد.
محل استقرار زیرساخت: انتخاب معماری On-Premise یا Hybrid باید بر اساس سیاست‌های امنیتی، الزامات نظارتی و محدودیت‌های زیرساختی بانک انجام شود. استفاده از خدمات ابری نباید بدون بررسی الزامات سازمان فرض پیش‌فرض باشد.
مدیریت دسترسی: تمام کاربران و سامانه‌ها نباید به اطلاعات خام بانکی دسترسی مستقیم داشته باشند. تعریف سطح دسترسی مبتنی بر نقش، رمزنگاری اطلاعات و ثبت سوابق دسترسی ضروری است.
حفاظت از اطلاعات حساس: اطلاعات هویتی، مالی و شناسه‌های مشتریان باید متناسب با سطح حساسیت، در محیط‌های تحلیلی و آزمایشی محافظت یا ماسک شوند.
تطبیق اطلاعات: اطلاعات منتقل‌شده باید با منبع اصلی مقایسه شوند. برای مثال، مجموع مانده حساب‌ها، تعداد تراکنش‌ها و مبالغ ثبت‌شده در سامانه مبدأ و مقصد باید بر اساس قواعد مشخص تطبیق داده شوند.
حاکمیت داده: مالکیت داده، تعریف شاخص‌ها، قواعد کیفیت و مسئولیت اصلاح مغایرت‌ها باید مشخص باشد. در غیر این صورت، حتی با وجود یکپارچگی فنی، اختلاف گزارش‌ها میان واحدهای بانک ادامه پیدا می‌کند
نقشه راه اجرای پروژه یکپارچه‌سازی
برای کاهش ریسک اجرایی، بهتر است پروژه از یک دامنه محدود شروع شود و به‌تدریج گسترش پیدا کند.
مرحله اول؛ شناسایی منابع و نیازهای کسب‌وکار: سامانه‌های اصلی، پایگاه‌های داده، مالکان اطلاعات و نیازهای گزارش‌گیری بانک شناسایی شوند. بهتر است در ابتدا یک حوزه مشخص مانند اطلاعات مشتریان یا سپرده انتخاب شود.
مرحله دوم؛ ارزیابی فنی منابع: امکان اتصال به پایگاه داده، دسترسی به لاگ‌ها، رابط‌های موجود، محدودیت‌های نسخه و ظرفیت زیرساخت بررسی شود.
مرحله سوم؛ طراحی مسیر انتقال: بر اساس ویژگی هر منبع، روش Batch، CDC یا API انتخاب شود. لایه دریافت و استانداردسازی نیز متناسب با این انتخاب طراحی شود.
مرحله چهارم؛ اجرای پایلوت: اطلاعات یک یا چند منبع منتخب به زیرساخت جدید منتقل و گزارش‌های اولیه تولید شوند.
مرحله پنجم؛ کنترل و گسترش: کیفیت داده، تأخیر انتقال، تطبیق اطلاعات و عملکرد سامانه‌ها ارزیابی شود. پس از تأیید نتایج، منابع دیگر به‌تدریج به معماری اضافه شوند.
همینطور بخوانید : حاکمیت داده در صنعت بانکی
خطاهای رایج در یکپارچه‌سازی سیستم‌های بانکی
اتصال مستقیم همه سامانه‌ها به پایگاه داده عملیاتی: این کار می‌تواند بار اضافی ایجاد کند و مدیریت دسترسی را دشوار سازد.
انتخاب یک روش انتقال برای همه منابع: نیازهای تازگی، حجم و امکانات فنی سامانه‌ها متفاوت است.
نادیده‌گرفتن کیفیت داده: انتقال اطلاعات بدون استانداردسازی، مغایرت‌های موجود را به بستر جدید منتقل می‌کند.
نبود سازوکار تطبیق: بدون کنترل مستمر مبدأ و مقصد، تشخیص خطا و از دست رفتن تغییرات دشوار خواهد بود.
تعریف‌نکردن مسئولیت‌ها: بدون تعیین مالک داده و شاخص، اختلاف‌های اطلاعاتی میان واحدهای سازمان باقی می‌ماند.
پرسش‌های متداول
آیا برای یکپارچه‌سازی سیستم‌های بانکی Legacy باید Core Banking تعویض شود؟
خیر. می‌توان هسته بانکی را به‌عنوان مرجع ثبت تراکنش حفظ کرد و از روش‌هایی مانند Batch، CDC و API برای اتصال آن به سایر سامانه‌ها و زیرساخت داده استفاده کرد.
کدام روش برای اتصال هسته بانکی به انبار داده مناسب‌تر است؟
پاسخ به امکانات فنی هسته و نیاز بانک بستگی دارد. CDC برای انتقال تغییرات مکرر، Batch برای داده‌های دوره‌ای و API برای تبادل سرویس‌محور مناسب است. در بسیاری از پروژه‌ها ترکیبی از این روش‌ها استفاده می‌شود.
آیا می‌توان سامانه‌های بانکی مبتنی بر Oracle را به زیرساخت داده جدید متصل کرد؟
بله. با بررسی نسخه پایگاه داده، سازوکارهای دسترسی و ابزارهای سازگار می‌توان داده‌های Oracle را از طریق روش‌های مختلف به زیرساخت تحلیلی منتقل کرد.
آیا یکپارچه‌سازی داده بانکی حتماً به زیرساخت ابری نیاز دارد؟
خیر. این معماری می‌تواند به‌صورت On-Premise یا Hybrid طراحی شود. انتخاب محل استقرار به الزامات امنیتی، سیاست‌های بانک و ظرفیت زیرساخت وابسته است.
تفاوت یکپارچه‌سازی سامانه‌های بانکی با نوسازی هسته بانکی چیست؟
یکپارچه‌سازی بر برقراری ارتباط و تبادل داده میان سامانه‌های موجود تمرکز دارد؛ اما نوسازی هسته بانکی به تغییر یا جایگزینی فناوری و قابلیت‌های عملیاتی Core Banking مربوط می‌شود. این دو پروژه می‌توانند مستقل یا در کنار یکدیگر اجرا شوند.
جمع‌بندی
یکپارچه‌سازی سیستم‌های بانکی Legacy، راهکاری برای استفاده مؤثر از اطلاعات پراکنده بانک بدون الزام به تعویض فوری سامانه‌های عملیاتی است. با انتخاب روش مناسب انتقال داده، ایجاد لایه استانداردسازی و اتصال منابع به زیرساخت داده سازمانی، می‌توان بستری قابل اتکا برای گزارش‌گیری، هوش تجاری و تحلیل‌های پیشرفته ایجاد کرد.
موفقیت چنین پروژه‌ای فقط به انتخاب ابزار وابسته نیست؛ شناخت منابع، کیفیت داده، امنیت، تطبیق اطلاعات و حاکمیت داده نیز در آن نقش اساسی دارند. شروع از یک حوزه محدود و گسترش تدریجی، مسیر عملی‌تری برای رسیدن به یک معماری داده یکپارچه در بانک‌ها فراهم می‌کند.