স্কেল করে এমন KYC রিভিউ কিউ ডিজাইন

KYC রিভিউ কিউ হলো সেই ব্যাক-অফিস ওয়ার্কফ্লো, যেখানে যন্ত্র নিজে থেকে যে পরিচয় যাচাই শেষ করতে পারেনি তা মানুষের সামনে রাখা হয়। বেশিরভাগ আবেদন স্বয়ংক্রিয়ভাবে পাস হওয়া উচিত; কিউ আছে যারা পাস করে না তাদের জন্য। এর পুরো ডিজাইন-লক্ষ্য ছোট থাকা — শুধু প্রকৃত অস্পষ্টতা ধরে রাখা, আর কিছু নয় — কারণ যে কিউ এমন কেসে ভরে যায় যেগুলো যন্ত্রেরই সিদ্ধান্ত নেওয়া উচিত ছিল, তা নিয়ন্ত্রণ নয়, সাইনআপের সঙ্গে রৈখিকভাবে বাড়তে থাকা একটি bottleneck। কিউ ঠিক করলে ব্যাক অফিস ভলিউমের সঙ্গে নয়, exception-এর সঙ্গে স্কেল করে।

ইচ্ছাকৃতভাবে ছোট থাকা — এই একটি বৈশিষ্ট্যই পরের প্রতিটি সিদ্ধান্ত চালায়। শুরু করুন সেই বিভাজন দিয়ে যা কিউকে এমন রাখে।

Straight-through হলো লক্ষ্য, কিউ ব্যতিক্রম

Straight-through processing (STP) মানে একটি আবেদন কোনো মানুষের স্পর্শ ছাড়াই শুরু থেকে শেষ পর্যন্ত পাস হয়: ডকুমেন্ট পড়া, পরিচয় মেলানো, sanctions ও PEP screening পরিষ্কার, liveness উত্তীর্ণ, সিদ্ধান্ত রেকর্ড করা। এটিই সাধারণ পথ হওয়া উচিত, আর যত শতাংশ আবেদন এ পথে যায় — STP rate — সেই একমাত্র সংখ্যা যা বলে দেয় কিউ স্কেল করবে কি না। নব্বইয়ের কোঠায় শতাংশ স্বয়ংক্রিয়ভাবে পাস হলে মানুষের কিউতে সামলানোর মতো ক্ষীণ ধারা থাকে; অর্ধেক রিভিউতে ঝরে পড়লে প্রবৃদ্ধির সঙ্গে তাল মিলিয়ে আপনাকে রিভিউয়ার নিয়োগ দিতে হয়। কিউ সেই জায়গা নয় যেখানে KYC ঘটে। এটি সেই জায়গা যেখানে স্বয়ংক্রিয় KYC স্বীকার করে যে সে নিশ্চিত নয়। STP rate বাড়ান, বাকি সব সংখ্যা এমনিতেই ভালো হবে: কম কেস কিউতে, কম অপেক্ষা, কম রিভিউয়ার নিয়োগ। এটিকে সরাসরি আক্রমণ করা উচিত — ক্লায়েন্টে ভালো ডকুমেন্ট ক্যাপচার, ছবি তোলার আগে স্পষ্ট নির্দেশনা, matching threshold এমনভাবে টিউন করা যাতে অতি-সতর্ক নিয়মে প্রকৃত গ্রাহক ফিরে না যান — কারণ এখানে ফিরে পাওয়া প্রতিটি শতাংশ পয়েন্ট এমন একটি কেস যা কারও বিকেল দখল করবে না।

কিউতে কী আসে, এবং কেন

কেস রিভিউতে ঝরে পড়ে নির্দিষ্ট, নামযোগ্য কারণে, আর কারণই একটি কেসের সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্য। ডকুমেন্টের ছবি পড়ার মতো স্পষ্ট নয়। ID-তে থাকা নাম আর আবেদনের নাম মেলে না। Sanctions বা PEP screening একটি সম্ভাব্য হিট দিয়েছে, যা মানুষকে নিশ্চিত বা খারিজ করতে হবে। কোনো সূত্রে ঠিকানা যাচাই করা যাচ্ছে না। Liveness চেক ব্যর্থ হয়েছে, অথবা একই মুখ বা ডকুমেন্ট ইতিমধ্যে অন্য অ্যাকাউন্টে আছে। এর প্রতিটি আলাদা ধরনের কাজ, আলাদা ধরনের বিচারবুদ্ধি দাবি করে — আর এগুলোকে একটি অভেদ স্তূপে ফেলাই রিভিউ কিউর প্রথম ভুল। একই কারণের ওজনও ভীষণ আলাদা হতে পারে: নামের অমিল বিবাহের পর নাম বদলের মতো সাধারণ ব্যাপারও হতে পারে, আবার চুরি হওয়া পরিচয়ের প্রথম লক্ষণও হতে পারে; কিউর কাজ হলো তা এমন কারও কাছে পাঠানো যিনি পার্থক্য বুঝতে পারেন, যত্নের দাবিদার কেসে তড়িঘড়ি রায় চাপিয়ে দেওয়া নয়।

একটি কিউ যথেষ্ট নয়: কারণ অনুযায়ী ভাগ করুন

একটি মাত্র কিউ প্রত্যেক রিভিউয়ারকে generalist হতে বাধ্য করে এবং প্রতিটি কেসকে সম্পর্কহীন কেসের পেছনে অপেক্ষা করায়। কারণ অনুযায়ী ভাগ করলে দুটোরই সমাধান হয়। Sanctions possible-match কিউ চালান screening ও disposition-এ প্রশিক্ষিত লোকেরা; ডকুমেন্ট-কোয়ালিটি কিউ একটি দ্রুত চাক্ষুষ যাচাই, যা জুনিয়র রিভিউয়ার কয়েক সেকেন্ডে শেষ করেন; duplicate-account কিউ একটি ফ্রড তদন্ত। প্রতিটি সেগমেন্ট পায় নিজস্ব routing, নিজস্ব প্রয়োজনীয় দক্ষতা এবং নিজস্ব service-level লক্ষ্য, কারণ ঝাপসা ছবি মিনিটের মধ্যে সমাধান হওয়া উচিত, অথচ প্রকৃত sanctions হিট চায় সতর্ক, তাড়াহীন disposition। Segmentation-ই throughput ও কঠোরতাকে একে অপরের বিনিময়ে না গিয়ে একসঙ্গে থাকতে দেয়।

শুধু রিভিউয়ার নিয়োগ দিয়ে review queue scale করা যায় না। scale হয় তখন, যখন সঠিকভাবে ঠিক করা যায় কোন কেসে রিভিউয়ারের দরকারই ছিল না — আর যেগুলোর দরকার, সেগুলো কারণ অনুযায়ী আগেই সাজানো অবস্থায় পৌঁছায়।

কারণ-আবশ্যক, অডিটযোগ্য অ্যাকশন

রিভিউয়ারের প্রতিটি সিদ্ধান্ত — approve, reject, escalate, আরও ডকুমেন্ট চাওয়া — অবশ্যই একটি কারণসহ হতে হবে এবং রেকর্ড হতে হবে। কারণটি পরে লেখা কোনো ফ্রি-টেক্সট নয়, বরং অ্যাকশন নেওয়ার মুহূর্তেই নেওয়া একটি structured নির্বাচন, যা বলে কেন সিদ্ধান্তটি নেওয়া হয়েছে। এটা আমলাতন্ত্র নয়; এটাই queue-কে যুক্তিসঙ্গতভাবে রক্ষণযোগ্য করে। কোনো ফ্ল্যাগ থাকা সত্ত্বেও একটি অ্যাকাউন্ট কেন approve হলো — রেগুলেটর, অডিটর বা পরের কোনো রিভিউয়ার এ প্রশ্ন করলে উত্তর হয় একজন নির্দিষ্ট রিভিউয়ার, একটি টাইমস্ট্যাম্প ও একটি উল্লেখিত কারণ — কাঁধ ঝাঁকানো নয়। অডিট ট্রেইল append-only, তাই কোনো সিদ্ধান্ত পরে চুপিসারে বদলানো যায় না; সংশোধন মানে নতুন এন্ট্রি, পুরনোটির ওপর এডিট নয়। আমাদের stack-এ এই queue ও তার অডিট মডেল থাকে Protocore Center (/products/center)-এ — অপারেটর কনসোল, যেখানে প্রতিটি privileged অ্যাকশনে কারণ দিতে হয় এবং তা এমন লগে যায় যা নীরবে বদলানো যায় না।

ফোর-আইজ কেস

কিছু সিদ্ধান্ত একজনের হাতে ছাড়ার মতো নয়। সত্যিকারের sanctions হিট ক্লিয়ার করা, high-risk প্রোফাইল approve করা, বা স্বয়ংক্রিয় rejection override করার ক্ষেত্রে দ্বিতীয় একজন রিভিউয়ারের নিশ্চিতকরণ থাকা উচিত — maker-checker, অর্থাৎ four-eyes। প্রথম রিভিউয়ার প্রস্তাব দেন ও কারণ লেখেন; ক্ষমতাপ্রাপ্ত দ্বিতীয়জন নিশ্চিত বা প্রত্যাখ্যান করেন এবং নিজের কারণ লেখেন। দুটি অ্যাকশনই লগ হয়। এটা রিভিউয়ারদের অবিশ্বাস নয়; বরং স্বীকৃতি যে সবচেয়ে ঝুঁকিপূর্ণ approval-গুলোতেই একটি ভুলের দাম সবচেয়ে বেশি, আর দ্বিতীয় জোড়া চোখ তার বিরুদ্ধে সবচেয়ে সস্তা বিমা। queue-র ডিজাইনে এই কেসগুলো কারণ অনুযায়ী স্বয়ংক্রিয়ভাবে দুই ধাপের নিষ্পত্তিতে যাওয়া উচিত, রিভিউয়ারের মনে রাখার ওপর নির্ভর না করে। তবে দুই ধাপ ইচ্ছাকৃতভাবে শুধু গুরুত্বপূর্ণ কেসের জন্য রাখুন; সবকিছুতে প্রয়োগ করলে পুরো queue-র খরচ দ্বিগুণ হয় এবং রিভিউয়াররা দ্বিতীয় স্বাক্ষরে চোখ বুজে সই করতে শেখে, যা নীরবে এর উদ্দেশ্যটাই নষ্ট করে।

ভলিউমের জন্য ডিজাইন: aging, prioritization, SLA

যে queue শুধু বাড়ে, সে queue ব্যর্থ। এমন চাপ ডিজাইনেই রাখুন যা তাকে চলমান রাখে। কেস কতদিন পড়ে আছে তা স্পষ্ট দেখা যাবে, যাতে কিছুই ভুলে পড়ে না থাকে; প্রতিটি segment-এর নিজস্ব service-level লক্ষ্য থাকবে, ফলে কয়েক মিনিটের SLA ভাঙা ঝাপসা-ছবির কেস আর তুলনামূলক দীর্ঘ SLA-র মধ্যে থাকা sanctions কেস আলাদাভাবে সামনে আসবে। prioritization একটি সত্যিকারের সিদ্ধান্ত: oldest-first ন্যায্য ও সহজ, কিন্তু risk-first — সবচেয়ে বড় সম্ভাব্য এক্সপোজার সবার ওপরে — প্রায়ই সঠিক পছন্দ, আর aging থাকে tiebreaker হিসেবে, যাতে low-risk কেসগুলো না খেয়ে থেকে ক্লিয়ার হয়। রিভিউয়ারের স্ক্রিনে আসা উচিত পরবর্তী কেস, আগে থেকেই routed ও prioritized — বেছে নেওয়ার তালিকা নয়, কারণ যে queue থেকে মানুষ বেছে তোলে, সেখানে ঝামেলার কেসগুলো কখনো তোলাই হয় না। দৃশ্যমান aging ছাড়া queue নীরবে পচে: কঠিন কেস নিচে ডুবে যায়, সহজগুলো ওপরে ঘুরতে থাকে, আর যে একটি মেট্রিক এটা ধরিয়ে দিত — সবচেয়ে পুরনো খোলা কেসের বয়স — গ্রাহক অভিযোগ না করা পর্যন্ত ঠিক সেই সংখ্যাটিই কেউ দেখে না।

queue পরিমাপ

চারটি সংখ্যা বলে দেয় ডিজাইনটি কাজ করছে কি না। STP rate বলে কতটা কাজে মানুষের দরকারই হয়নি; queue depth ও তার ট্রেন্ড বলে আপনি তাল রাখছেন নাকি পিছিয়ে পড়ছেন; প্রতিটি segment-এর SLA-র বিপরীতে ট্র্যাক করা time-to-decision বলে গ্রাহকরা অনবোর্ডিংয়ের জন্য বেশি অপেক্ষা করছেন কি না; আর reopen rate — পরে উল্টে যাওয়া সিদ্ধান্ত — বলে রিভিউয়াররা সঠিকভাবে সিদ্ধান্ত নিচ্ছেন, নাকি শুধু দ্রুত। এগুলো একসাথে দেখুন, কারণ এরা একে অপরের বিনিময়ে চলে: reopen rate বাড়ার সময় time-to-decision কমানোর অর্থ আপনি ভুলের বিনিময়ে গতি কিনেছেন। সুস্থ queue ছোট, চলমান, সঠিকভাবে সিদ্ধান্ত নেওয়া, এবং এখনও খোলা কেসগুলো নিয়ে সৎ।

মানুষ যে back office কল্পনা করে — ঘরভর্তি কর্মী আবেদনের পর আবেদন হাতে এন্ট্রি করছে — সেটাই পাওয়া যায় যখন অটোমেশন খুব কম ক্লিয়ার করে এবং queue একটি অভিন্ন স্তূপ হয়ে থাকে। যে back office scale করে সেটা ঠিক উল্টো: বেশিরভাগ আবেদন কখনো মানুষের কাছে পৌঁছায় না, যেগুলো পৌঁছায় সেগুলো কারণ ও অগ্রাধিকার অনুযায়ী সাজানো থাকে, প্রতিটি অ্যাকশন কারণসহ append-only লগে যায়, আর যেসব সিদ্ধান্তের দরকার সেগুলোতে four-eyes পাহারা দেয়। queue বানান ব্যতিক্রমের জন্য, তাহলে আপনি বড় হলেও সেটি ছোট থাকবে। বানান KYC হওয়ার জায়গা হিসেবে, তাহলে প্রতিটি নতুন signup-এর সাথে সেটিও বাড়বে।