در بسیاری از بانکها، مفهوم «مشتری» در هر سامانه تعریف جداگانهای دارد. سامانهٔ بانکداری متمرکز یک شمارهٔ مشتری دارد، سامانهٔ کارت شمارهٔ دیگری، سامانهٔ تسهیلات شمارهٔ سوم و کانالهای دیجیتال شمارهٔ چهارم. یک شخص حقیقی ممکن است در سه سامانه با سه املای متفاوت نام، دو نشانی قدیمی و یک شمارهٔ تماس منسوخ ثبت شده باشد. تا زمانی که هر سامانه بهتنهایی کار میکند، این پراکندگی پنهان میماند؛ اما همین که بانک بخواهد نمای یکپارچه، تحلیل ریسک یا خدمت شخصیسازیشده ارائه دهد، مشکل به سطح میآید.
اهمیت این موضوع فراتر از نظافت داده است. شناخت درست مشتری پایهٔ مقررات شناسایی مشتری، مدیریت ریسک اعتباری، جلوگیری از تقلب و حتی محاسبهٔ درست سودآوری است. اگر بانک نتواند بگوید که سه حساب، دو کارت و یک تسهیلات به یک شخص تعلق دارند، نه میتواند ریسک تجمیعی او را بسنجد و نه میتواند تجربهٔ منسجمی در شعبه و اپلیکیشن ارائه دهد. علاوه بر این، اشخاص حقوقی و روابط میان آنها، مثل سهامداری، نمایندگی و ضمانت، لایهای پیچیدهتر میسازند که با جدول سادهٔ مشتریان قابل مدلسازی نیست.
راهحل معماری، ایجاد یک مرجع واحد برای «شخص» است که در ادبیات فنی به آن Party Master Data میگویند. در این مدل، شخص حقیقی، شخص حقوقی و حتی نقشهای میانی مثل وکیل یا ذینفع، همگی زیر مفهوم عام «Party» تعریف میشوند و روابط میان آنها بهصورت صریح ذخیره میشود. سامانهٔ مرجع، هویت طلایی هر شخص را نگهداری میکند، شناسههای محلی سامانههای دیگر را به آن نگاشت میکند و از طریق API و رویداد، تغییرات را به همهٔ مصرفکنندگان اطلاع میدهد. سامانههای عملیاتی همچنان دادهٔ خود را دارند، اما دیگر منبع حقیقت نیستند.
نخستین ملاحظهٔ عملی، قواعد تطبیق و ادغام است. شناسایی اینکه دو رکورد به یک شخص تعلق دارند، ترکیبی از قواعد قطعی، مثل کد ملی یا شناسهٔ ثبت، و قواعد احتمالی، مثل شباهت نام و تاریخ تولد، است. این قواعد باید شفاف، قابل تنظیم و قابل بازبینی باشند، زیرا هر ادغام اشتباه میتواند حساب دو نفر را به هم پیوند بزند. برای مثال، وقتی دو رکورد با نام مشابه و تاریخ تولد یکسان اما نشانی متفاوت پیدا میشود، سیستم باید آن را بهجای ادغام خودکار، برای بازبینی انسانی علامتگذاری کند.
دومین ملاحظه، مدلسازی روابط است. در بانکداری شرکتی، ارزش واقعی از فهم شبکهٔ روابط به دست میآید: کدام شرکتها زیرمجموعهٔ یک هلدینگ هستند، چه کسی امضای مجاز دارد، کدام شخص ضامن کدام تسهیلات است. این روابط باید با نوع، تاریخ شروع و پایان و منبع ثبت ذخیره شوند تا هم قابل استعلام باشند و هم قابل حسابرسی. یک مدل خوب اجازه میدهد بانک بپرسد «همهٔ تعهدات مرتبط با این گروه اقتصادی چقدر است؟» و پاسخی یکپارچه بگیرد.
دامهای رایج در پروژههای دادهٔ مرجع اشخاص قابل تشخیصاند. اول، تلاش برای مهاجرت همهٔ سامانهها بهیکباره، که پروژه را به یک برنامهٔ چندساله بدون نتیجهٔ میانی تبدیل میکند. دوم، بیتوجهی به مالکیت داده؛ اگر مشخص نباشد کدام واحد سازمانی مسئول کیفیت هر ویژگی است، دادهٔ مرجع بهسرعت دوباره آلوده میشود. سوم، ساختن سامانهٔ مرجع بدون API و رویداد، بهطوری که سامانههای دیگر مجبور شوند داده را با فایل و زمانبندی شبانه دریافت کنند. و چهارم، نادیده گرفتن تاریخچه؛ بانک باید بتواند وضعیت یک شخص را در تاریخ مشخصی در گذشته بازسازی کند.
پلتفرم «آشنا» در نیاداد دقیقاً برای همین نقش طراحی شده است: مدیریت یکپارچهٔ اشخاص حقیقی و حقوقی، روابط میان آنها، قواعد تطبیق قابل تنظیم و انتشار تغییرات از طریق API و رویداد. «آشنا» در پروژهٔ بانکی نیاداد بهعنوان مرجع اشخاص در کنار لایهٔ هویت و درگاه API قرار گرفته تا سامانههای عملیاتی، کانالهای دیجیتال و تحلیل داده همگی از یک تعریف مشترک از مشتری استفاده کنند.
دادهٔ مرجع اشخاص جذابترین پروژهٔ یک بانک نیست، اما پیشنیاز تقریباً همهٔ پروژههای جذاب است. بدون آن، هوش مصنوعی روی دادهٔ نادرست آموزش میبیند، نمای ۳۶۰ درجه ناقص میماند و مدیریت ریسک بر حدس تکیه میکند. با آن، هر پروژهٔ بعدی از نقطهای مطمئن آغاز میشود. هرچه بانک زودتر دادهٔ اشخاص را بهجای دغدغهٔ یک واحد، زیرساخت مشترک بداند، بقیهٔ نقشهٔ راهش زودتر دستیافتنی میشود.