একটি core, অনেক অ্যাপ: whitelabel banking platform কীভাবে কাজ করে
whitelabel banking platform হলো একটি banking core, যার front end বদলানো যায়। core হলো সেই অংশ, যা নির্ভুল হতেই হবে: double-entry ledger, গ্রাহকের অ্যাকাউন্ট, KYC ও onboarding, কার্ড issuing ও processing, crypto ও stablecoin rail, এবং এ সবকিছুর পেছনে চলা operator console। অ্যাপ হলো সেই অংশ, যা গ্রাহক দেখে — তার নাম, রং, স্ক্রিনের গড়ন, কোন ফিচারগুলো চালু আছে। Whitelabel মানে একটি core অনেক রূপ ধারণ করতে পারে, প্রতিটির নিচে নতুন করে না বানিয়েই। একটি core, অনেক অ্যাপ।
সোজা কথায়, এটি seam কোথায় বসে সে সম্পর্কে একটি দাবি। অর্থ-সংক্রান্ত সবকিছু শেয়ার্ড, audited এবং একবারই reconcile করা; গ্রাহক-সংক্রান্ত সবকিছু প্রতি tenant-এ কনফিগার করা। আসল ইঞ্জিনিয়ারিং হলো এই রেখাটি সৎ রাখা — front end স্বাধীনভাবে ভিন্ন হোক, কিন্তু যে core-এর ওপর সে দাঁড়িয়ে, সেটি কখনো fork না হোক। এই লেখায় দেখা হয়েছে রেখাটি কীভাবে টানা হয়, এবং কেন fork দিয়ে টানার চেয়ে design token দিয়ে টানা ভালো।
যা কখনো বদলায় না: core
শুরু করা যাক সেই অর্ধেক দিয়ে, যেখানে সৃজনশীল হওয়ার অনুমতি নেই। অ্যাপ একে send, payment বা payout, যা-ই বলুক, একটি ট্রান্সফার একইভাবে পোস্ট হয়: double-entry ledger-এ দুটি এন্ট্রি, এবং কিছুই কখনো মোছা হয় না — ledger শুধু যোগ করে, তাই refund হলো মূল এন্ট্রির রেফারেন্স দেওয়া একটি counter-entry, মুছে ফেলা নয়। অ্যাকাউন্ট, ব্যালান্স ও authorization hold এখানেই থাকে। KYC ও onboarding, কার্ড issuing ও settlement, এবং crypto ও stablecoin rail-ও তা-ই। এসবের পেছনে আছে একটিমাত্র operator console, যেখানে প্রতিটি privileged action-এ কারণ দেওয়া বাধ্যতামূলক এবং তা audit log-এ জমা পড়ে।
এগুলোর প্রতিটির ঠিক একটিই আছে, আর সেটাই মূল কথা। Settlement, reconciliation ও compliance ঠিকভাবে করা কঠিন, ভুল হলে খরচ বেশি, তাই এগুলো একবার বানান আর প্রতিটি অ্যাপ ফলাফলটি পেয়ে যাক। কোনো tenant গ্রাহককে onboard করলে core যে KYC tier নির্ধারণ করে, তা গ্রাহকের সঙ্গে console-এ যায়, কোন অ্যাপের স্ক্রিনে ডকুমেন্ট নেওয়া হয়েছে তাতে কিছু আসে-যায় না। ওপরের অ্যাপের নাম কী, core তা জানে না, পরোয়াও করে না — সে দেখে অ্যাকাউন্ট ও এন্ট্রি, ব্র্যান্ড নয়।
যা বদলায়: ডিজাইন ভাষা, information architecture, ফিচার মিশ্রণ
core-এর ওপরের সবকিছু তিনটি অক্ষে স্বাধীনভাবে বদলাতে পারে। প্রথমটি ডিজাইন ভাষা: রং, টাইপোগ্রাফি, কোণের radius, spacing, motion — ব্র্যান্ডের ভিজ্যুয়াল ব্যাকরণ। দ্বিতীয়টি information architecture: হোম স্ক্রিনে কী থাকবে, flow-এর নাম ও ক্রম কী হবে, কোন action এক ট্যাপ দূরে আর কোনটি তিন ট্যাপ। তৃতীয়টি ফিচার মিশ্রণ: কোন module আদৌ চালু থাকবে। একটি সরল transfers অ্যাপ আর একটি ঠাসা super-app একই core চালাতে পারে, অথচ একটি স্ক্রিনও ভাগ করে না।
/products/pay-এর প্রোডাক্ট পেজে পাঁচটি কার্যকর direction দেখানো আছে, এবং এগুলো পাঁচটির মেনু নয়, অসংখ্য সম্ভাবনার উদাহরণ হিসেবে পড়াই ভালো। Halcyon একটি পরিচ্ছন্ন exchange — সংযত, অল্প স্ক্রিন, ট্রেড সামনে। Lumen একটি super-app, যেখানে কথোপকথনের ভেতরেই অর্থ চলে এবং chat payments, subscriptions ও earn একই হোম স্ক্রিনে থাকে। Fern শুরু করে ট্রান্সফার দিয়ে — আগে আসে batch payout ও rule-based FX conversion। Volt একটি stablecoin-dark বিল্ড, যাতে আছে salary sorter ও team cards। Meridian বহু-মুদ্রার: USDC-র পাশে EUR অ্যাকাউন্ট, GBP travel balance, আর একটি BTC অ্যাকাউন্ট, যেখানে কার্ড রিওয়ার্ড জমা হয়। পাঁচটি ব্র্যান্ড, পাঁচটি information architecture, পাঁচটি ফিচার মিশ্রণ — সবার নিচে একটিই ledger, একটিই KYC, একটিই কার্ড processor।
এর কোনোটির মানে এই নয় যে প্রোডাক্টটি পাঁচটি অ্যাপ। পাঁচটি হলো একই pipeline যেসব পথ নিতে পারে তার উদাহরণ; যে সংখ্যাটি আসল, তা পাঁচ নয়, আপনি যতগুলো tenant onboard করবেন ততটি। প্রতিটি একেকটি প্রমাণ যে front end হোম স্ক্রিনের গড়ন পর্যন্ত আলাদা হতে পারে, অথচ নিচের core টেরও পায় না।
core হলো সেই অংশ, যা আপনি নতুন করে আবিষ্কার করতে পারবেন না; অ্যাপ হলো সেই অংশ, যাকে আপনি বেঁধে ফেলতে পারবেন না। whitelabel platform হলো এই দুটি বাক্যকে একসঙ্গে সত্য রাখার শৃঙ্খলা।
কেন codebase fork করার চেয়ে token-level theming ভালো
একটি প্রোডাক্টকে অনেক প্রোডাক্টের মতো দেখানোর দুটি উপায় আছে। সহজ উপায়টি হলো fork: প্রতিটি গ্রাহকের জন্য codebase কপি করুন, রি-স্টাইল করুন, শিপ করুন। এটি কাজ করে ঠিক একটি রিলিজ পর্যন্ত। তারপর প্রতিটি bug fix ও প্রতিটি রেগুলেটরি পরিবর্তন N-টি ক্রমে আলাদা হয়ে যাওয়া কপিতে N বার প্রয়োগ করতে হয়, কপিগুলো সিঙ্ক থেকে ছিটকে পড়ে, আর যে security surface আপনাকে বুঝতে হয় তা গ্রাহকসংখ্যা দিয়ে গুণ হয়ে যায়। fork এমন একটি সিস্টেমকে, যা আপনি বোঝেন, অনেকগুলো সিস্টেমে পরিণত করে, যেগুলো আপনি বোঝেন না।
Token-level theming এটিকে উল্টে দেয়। codebase একটিই। ব্র্যান্ড হলো একগুচ্ছ মান — রং, টাইপ, radius ও spacing-এর token; একটি component configuration; একটি feature-flag সেট — যা build time-এ ব্র্যান্ডেড অ্যাপে রূপ নেয়। একটি token বদলালে সেটি পড়া প্রতিটি স্ক্রিন একসঙ্গে বদলায়, কারণ token থেকে যে মান আসার কথা তা কোথাও hardcode করা নেই। ট্রান্সফার flow-এর একটি fix একসঙ্গে প্রতিটি tenant-এর কাছে পৌঁছায়, কারণ ঠিক করার মতো ট্রান্সফার flow একটিই। ব্র্যান্ডগুলো আলাদা তাদের configuration-এ, source-এ নয়।
ডিজাইন সিস্টেম কোথায় বসে
token কোনো আলগা ধারণা নয়; এটি একটি শিপ করা আর্টিফ্যাক্ট। Protocore Design System — /products/pds — হলো 144টি design token ও 889টি utility class: প্রতিটি অ্যাপ যে শব্দভান্ডারে থিম করা হয়। এটি dark-first, token-driven এবং ডিফল্টভাবে radius zero, আর একই token সেট web, .NET ও native-এর জন্য তৈরি হয়, তাই একবার সংজ্ঞায়িত একটি রং React স্ক্রিন, ডেস্কটপ console ও native মোবাইল বিল্ডে একই রং বোঝায়। tenant-এর ব্র্যান্ড প্রকাশ পায় এই শব্দভান্ডারের ওপর override হিসেবে, আর সে কারণেই অ্যাপ re-skin করা একটি configuration পরিবর্তন, rewrite নয়।
এটিই front end-কে সত্যিই স্বাধীন করে, টেমপ্লেটের ভেতরের স্বাধীনতার বদলে। কারণ ডিজাইন ভাষা one-off stylesheet-এ নয়, token ও utility class-এ থাকে, তাই একজন ডিজাইনার core না ছুঁয়ে বা অ্যাপ fork না করেই একটি tenant-কে রেফারেন্স বিল্ড থেকে বহুদূর নিয়ে যেতে পারেন — নিজস্ব palette, টাইপ, density ও ছন্দ সহ। রং অনেক গভীরে যায়, তবু সেটি রংই; নিচের plumbing শেয়ার্ড।
অ্যাপ একটি configuration, বিল্ড নয়
ফিচার মিশ্রণও একই নিয়মে চলে। প্রতিটি module — chat payments, earn, crypto, cards, subscriptions, team cards, referrals — প্রতি tenant-এ চালু করার একটি সুইচ, এবং একটি flag ব্যাপকভাবে ছাড়ার আগে ব্যবহারকারীদের একটি অংশে রোল আউট করা যায়। অপারেটররা এগুলো config panel থেকে ওঠানামা করান, deploy করে নয়। তাই একটি সরল transfers অ্যাপ আর পূর্ণ super-app-এর পার্থক্য দুটি প্রজেক্ট নয়; একই প্রজেক্টের দুটি configuration। প্রতিটি tenant যে রেফারেন্স অ্যাপ থেকে শুরু করে, সেটি একটি নিরপেক্ষ, Protocore-ব্র্যান্ডেড বিল্ড, যেখানে পুরো মেনু আছে — প্রতিটি whitelabel হলো সেই বিল্ড, যেখানে token override করা হয়েছে এবং module চালু বা বন্ধ করা হয়েছে।
স্পষ্ট সীমারেখা
একটি core, অনেক অ্যাপ — এই যন্ত্রপাতির খরচ তখনই সার্থক, যখন আপনার সত্যিই অনেক অ্যাপ আছে — অথবা এমন একটি অ্যাপ, যা আপনি সময়ের সঙ্গে re-skin, re-arrange ও re-scope করতে চান, প্রতিবার ব্যাংক নতুন করে না বানিয়ে। যদি আপনি একটিমাত্র স্থির অ্যাপ শিপ করেন, যা কখনো দ্বিতীয় ব্র্যান্ড পরবে না, তাহলে whitelabel platform লাগে না; লাগে একটি অ্যাপ। এর আসল মূল্য সেই ক্ষেত্রে, যার জন্য এটি বানানো: এমন একটি প্ল্যাটফর্ম, যা একের পর এক tenant-এর জন্য ব্র্যান্ডেড ব্যাংকিং প্রোডাক্ট দাঁড় করায়, প্রতিটি স্পষ্টতই নিজস্ব, কোনোটিই fork নয়। পূর্ণ বিশ্লেষণ — পাঁচটি direction, রেফারেন্স অ্যাপ ও তাদের পেছনের operator console — আছে /products/pay-তে, আর নিচের design system আছে /products/pds-এ।
কোনো সিস্টেম বানাতে চান?
সমস্যাটা আমাদের জানান। আমরা আর্কিটেকচার ও একটি পরিকল্পনা নিয়ে ফিরে আসব।