في كثير من البنوك، يُعرَّف مفهوم «العميل» تعريفًا منفصلًا في كل نظام. فللنظام المصرفي الأساسي رقم عميل، ولنظام البطاقات رقم آخر، ولنظام التمويل رقم ثالث، وللقنوات الرقمية رقم رابع. وقد يُسجَّل الشخص الواحد في ثلاثة أنظمة بثلاث تهجئات لاسمه، وعنوانين قديمين، ورقم هاتف لم يعد أحد يجيب عليه. وما دام كل نظام يعمل بمعزل عن غيره، يبقى هذا التشتت خفيًا. لكن ما إن يريد البنك رؤية موحّدة أو تحليلًا للمخاطر أو خدمة مخصصة، حتى تطفو المشكلة على السطح.
تتجاوز الأهمية مجرد نظافة البيانات بكثير. فالمعرفة الصحيحة بالعميل هي أساس التزامات التعرف على العملاء، وإدارة مخاطر الائتمان، ومنع الاحتيال، بل وحتى الحساب الأمين للربحية. وإذا لم يستطع البنك أن يقول إن ثلاثة حسابات وبطاقتين وقرضًا واحدًا تعود إلى الشخص نفسه، فلن يتمكن من قياس إجمالي انكشافه ولا من تقديم تجربة متسقة بين الفرع والتطبيق. وتضيف الكيانات الاعتبارية والعلاقات بينها، كالمساهمة والتمثيل والضمانات، طبقة أخرى لا يستطيع جدول عملاء مسطح نمذجتها ببساطة.
الحل المعماري هو مصدر موحّد للحقيقة بشأن الطرف، يُعرف في الأدبيات التقنية بالبيانات الرئيسية للأطراف (Party Master Data). وفي هذا النموذج، يندرج الأشخاص الطبيعيون والكيانات الاعتبارية وحتى الأدوار الوسيطة كالوكلاء القانونيين أو المستفيدين تحت المفهوم العام «الطرف»، وتُخزَّن العلاقات بينهم بشكل صريح. ويحتفظ النظام المرجعي بالهوية الذهبية لكل طرف، ويربط بها المعرّفات المحلية لكل نظام آخر، وينشر التغييرات إلى جميع المستهلكين عبر واجهات API والأحداث. وتحتفظ الأنظمة التشغيلية ببياناتها، لكنها لم تعد مصدر الحقيقة.
الاعتبار العملي الأول هو قواعد المطابقة والدمج. فالحكم بأن سجلين يعودان إلى الشخص نفسه يجمع بين قواعد حتمية، كالرقم الوطني أو رقم التسجيل، وقواعد احتمالية، كتشابه الاسم وتاريخ الميلاد. ويجب أن تكون هذه القواعد شفافة وقابلة للضبط والمراجعة، لأن كل دمج خاطئ قد يربط حسابات شخصين معًا. فمثلًا، حين يتشارك سجلان اسمًا متشابهًا وتاريخ الميلاد نفسه لكن بعنوانين مختلفين، ينبغي للنظام أن يضع عليهما علامة للمراجعة البشرية بدلًا من دمجهما آليًا.
الاعتبار الثاني هو نمذجة العلاقات. ففي الخدمات المصرفية للشركات، تأتي القيمة الحقيقية من فهم الشبكة: أي الشركات تنتمي إلى مجموعة قابضة، ومن يملك صلاحية التوقيع، وأي شخص يضمن أي تسهيل. وتحتاج هذه العلاقات إلى نوع وتاريخ بداية ونهاية ومصدر مسجّل، لتكون قابلة للاستعلام والتدقيق معًا. والنموذج الجيد يتيح للبنك أن يسأل عن إجمالي الانكشاف تجاه مجموعة اقتصادية معينة ويتلقى إجابة واحدة متسقة بدلًا من جدول بيانات مُجمَّع يدويًا.
المزالق المعتادة في مشاريع البيانات الرئيسية للأطراف معروفة. أولًا، محاولة ترحيل كل الأنظمة دفعة واحدة، ما يحوّل المشروع إلى برنامج متعدد السنوات بلا نتائج مرحلية. ثانيًا، إهمال ملكية البيانات؛ فإذا لم تكن هناك وحدة أعمال مسؤولة عن جودة كل سمة، تتلوث البيانات الرئيسية مجددًا خلال أشهر. ثالثًا، بناء السجل الرئيسي دون واجهات API وأحداث، فينتهي الأمر بالأنظمة الأخرى إلى تلقي البيانات عبر ملفات ليلية. رابعًا، تجاهل السجل التاريخي؛ إذ يجب أن يتمكن البنك من إعادة بناء ما كان يعرفه عن طرف ما في تاريخ محدد في الماضي.
صُمّمت منصة آشنا من نياداد لهذا الدور تحديدًا: الإدارة الموحّدة للأشخاص الطبيعيين والاعتباريين والعلاقات بينهم، وقواعد مطابقة قابلة للضبط، ونشر التغييرات عبر واجهات API والأحداث. وفي البرنامج المصرفي لنياداد، تعمل آشنا مرجعًا رئيسيًا للأطراف إلى جانب طبقة الهوية وبوابة API، لتعمل الأنظمة التشغيلية والقنوات الرقمية والتحليلات جميعها وفق تعريف مشترك واحد للعميل.
ليست البيانات الرئيسية للأطراف أكثر المشاريع بريقًا في البنك، لكنها شرط مسبق لكل المشاريع البراقة تقريبًا. فمن دونها يتدرب الذكاء الاصطناعي على بيانات خاطئة، وتبقى رؤية العميل 360 درجة ناقصة، وتعتمد إدارة المخاطر على التخمين. ومعها ينطلق كل مشروع لاحق من أرضية صلبة. وكلما أسرع البنك في التعامل مع بيانات الأطراف بوصفها بنية تحتية مشتركة لا شأنًا خاصًا بإدارة واحدة، أصبح بقية خارطة طريقه قابلًا للتحقيق في وقت أقرب.