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