نحوه راه اندازی صرافی ارز دیجیتال؛ مراحل صفر تا صد

راه‌اندازی صرافی فقط به ساخت یک سایت، اپلیکیشن یا موتور معامله محدود نمی‌شود. در نحوه راه اندازی صرافی ارز دیجیتال، تصمیم‌هایی مانند مدل فعالیت، وضعیت حقوقی، نحوه نگهداری دارایی کاربران، نقدینگی و کنترل ریسک می‌توانند شکل زیرساخت فنی را تغییر دهند؛ به همین دلیل شروع مستقیم از برنامه‌نویسی معمولاً نقطه آغاز مناسبی نیست.

شناخت ترتیب درست مراحل کمک می‌کند پیش از صرف بودجه برای توسعه، ابهام‌های بنیادی پروژه را برطرف کنید و بدانید هر مرحله باید با چه خروجی‌ای تمام شود. در چنین مسیری، توسعه زمانی آغاز می‌شود که مدل فعالیت مشخص باشد و عرضه عمومی نیز وقتی انجام می‌شود که علاوه بر نرم‌افزار، عملیات واقعی صرافی آماده کار باشد.

مراحل راه اندازی صرافی ارز دیجیتال چیست؟

مراحل راه اندازی صرافی ارز دیجیتال از تعیین نوع فعالیت و بازار هدف شروع می‌شود. سپس باید وضعیت حقوقی، ساختار کسب‌وکار و مدل عملیاتی مشخص شوند. بعد از آن نوبت بودجه، زیرساخت فنی، امنیت و نگهداری دارایی، KYC و کنترل ریسک، نقدینگی و مسیرهای واریز و برداشت است. پیش از عرضه عمومی نیز باید کل فرایند در سناریوهای واقعی آزمایش شود و پس از شروع فعالیت، پایش، امنیت و پشتیبانی ادامه پیدا کند.

مسیر کلی را می‌توان در ۱۰ مرحله خلاصه کرد:

1. مدل صرافی و بازار هدف را مشخص کنید.
2. وضعیت حقوقی و الزامات فعالیت را بررسی کنید.
3. مدل کسب‌وکار و عملیات صرافی را طراحی کنید.
4. بودجه و روش اجرای پروژه را تعیین کنید.
5. زیرساخت فنی را براساس نیاز واقعی انتخاب و توسعه دهید.
6. امنیت و مدل نگهداری دارایی را طراحی کنید.
7. KYC، AML و کنترل ریسک را عملیاتی کنید.
8. نقدینگی و مسیرهای واریز و برداشت را آماده کنید.
9. صرافی را پیش از عرضه عمومی آزمایش کنید.
10. پس از راه‌اندازی، عملیات را به‌صورت مستمر پایش و مدیریت کنید.

اهمیت این ترتیب در وابستگی مراحل به یکدیگر است. اگر نوع فعالیت هنوز دقیق مشخص نشده باشد، معماری فنی نیز بر پایه فرضیات ساخته می‌شود. اگر الزامات حقوقی دیر بررسی شوند، ممکن است مدل عملیاتی نیازمند تغییر شود. همچنین اگر امنیت، نقدینگی یا فرایند برداشت آماده نباشند، آنلاین‌شدن سایت به معنی آماده‌بودن صرافی برای پذیرش کاربر نیست.

مرحله ۱: مدل صرافی و بازار هدف را مشخص کنید

اولین تصمیم این نیست که سایت با چه فناوری ساخته شود یا ظاهر پنل معاملات چگونه باشد. ابتدا باید مشخص کنید دقیقاً چه کسب‌وکاری قرار است ایجاد شود و برای چه گروهی از کاربران خدمت ارائه کند.

در این مرحله به پرسش‌هایی از این جنس پاسخ دهید:

• بازار جغرافیایی فعالیت کجاست؟
• کاربران هدف چه کسانی هستند؟
• چه خدماتی در نسخه اولیه ارائه می‌شوند؟
• چه دارایی‌ها و بازارهایی پشتیبانی خواهند شد؟
• آیا مجموعه دارایی کاربران را نگهداری می‌کند؟
• مدل معاملات چگونه است؟
• کدام قابلیت‌ها برای شروع ضروری‌اند؟
• چه امکاناتی می‌توانند بعد از راه‌اندازی اضافه شوند؟

نوع صرافی روی بسیاری از تصمیم‌های بعدی اثر دارد. برای مثال، مدلی که خودِ مجموعه دارایی کاربران را نگهداری و حساب‌های داخلی را مدیریت می‌کند، از نظر معماری امنیت، کیف پول، کنترل دسترسی و عملیات با مدلی که چنین مسئولیتی ندارد یکسان نیست.

در این مرحله لازم نیست تمام جزئیات محصول را طراحی کنید. خروجی مطلوب یک تعریف روشن از دامنه پروژه است: چه خدمتی، برای چه کاربری، در چه بازاری و با چه مسئولیت‌هایی ارائه می‌شود.

اگر این تعریف در چند جمله قابل توضیح نیست و تیم هنوز درباره ماهیت اصلی محصول اختلاف دارد، ورود به توسعه فنی زود است.

مرحله ۲: وضعیت حقوقی و الزامات فعالیت را قبل از توسعه بررسی کنید

در ایران، طبق دستورالعمل تأسیس، فعالیت، انحلال و نظارت بر کارگزاران رمزپول، فعالیت به‌عنوان کارگزار رمزپول پس از اخذ مجوز فعالیت مجاز است. به همین دلیل، وضعیت حقوقی و الزامات جاری باید پیش از ورود جدی به اجرای پروژه بررسی شوند.

صرافی ارز دیجیتال یک کسب‌وکار عادی محتوایی یا فروشگاهی نیست. فعالیت آن می‌تواند با نگهداری دارایی، تبدیل دارایی مجازی، انتقال، خدمات مالی، شناسایی کاربران و کنترل ریسک‌های مالی در ارتباط باشد. به همین دلیل، بررسی حقوقی نباید به روزهای پایانی پروژه موکول شود.

قانون بانک مرکزی جمهوری اسلامی ایران، ایجاد و توسعه بازارهای متشکل ارز و رمزپول‌های مجاز را در حوزه وظایف بانک مرکزی قرار داده و تصمیم‌گیری درباره جواز یا عدم جواز نگهداری و مبادله انواع رمزپول را در چهارچوب قانون بر عهده هیأت عالی گذاشته است. بنابراین برنامه‌ریزی پروژه با این فرض که این حوزه الزام یا نظارت مشخصی ندارد، رویکرد قابل اتکایی نیست.

در کنار ماهیت خدمات، این موارد نیز باید بررسی شوند:

• ساختار حقوقی نهاد بهره‌بردار؛
• مالکیت و مسئولیت اشخاص حقوقی مرتبط؛
• مدل نگهداری دارایی کاربران؛
• نحوه ارائه خدمات تبدیل یا انتقال؛
• الزامات مرتبط با مبارزه با پول‌شویی و تأمین مالی تروریسم؛
• محدودیت‌های مرتبط با مسیرهای پرداخت و تسویه؛
• آخرین دستورالعمل‌ها و مقررات مراجع ذی‌ربط.

آیین‌نامه تنقیحی مقابله و پیشگیری از جرایم پول‌شویی و تأمین مالی تروریسم، ارائه خدمات دارایی مجازی را صریحاً دربر می‌گیرد؛ از جمله تبدیل دارایی مجازی به ریال یا ارز خارجی و بالعکس، تبدیل میان دارایی‌های مجازی، انتقال و نگهداری یا مدیریت آن‌ها. این آیین‌نامه همچنین بر رویکرد مبتنی بر ریسک در برنامه‌های مبارزه با پول‌شویی تأکید می‌کند.

این مقاله نمی‌تواند برای هر پروژه مشخص کند دقیقاً چه مجوز، سرمایه، مدرک یا فرایند اداری لازم است؛ زیرا پاسخ به مدل فعالیت و مقررات روز وابسته است. پیش از صرف هزینه سنگین برای توسعه، آخرین مقررات رسمی را بررسی کنید و در مسائل تخصصی از مشاور حقوقی آشنا با حوزه مالی و دارایی دیجیتال کمک بگیرید.

خروجی این مرحله باید روشن کند آیا مدل فعلی کسب‌وکار قابلیت ادامه دارد یا لازم است پیش از توسعه، بخشی از ساختار آن اصلاح شود.

مرحله ۳: مدل کسب‌وکار و عملیات صرافی را طراحی کنید

بعد از تعیین دامنه و بررسی امکان حقوقی فعالیت، باید مشخص شود کسب‌وکار در عمل چگونه کار می‌کند.

یک روش مفید این است که به‌جای شروع از فهرست قابلیت‌های نرم‌افزار، مسیر کاربر و دارایی را ترسیم کنید.

برای مثال:

کاربر چگونه ثبت‌نام می‌کند؟ چه زمانی و چگونه وارد فرایند شناسایی می‌شود؟ واریز چگونه ثبت می‌شود؟ موجودی در چه مرحله‌ای قابل استفاده است؟ سفارش چگونه ایجاد و اجرا می‌شود؟ برداشت چه کنترل‌هایی دارد؟ اگر تراکنش دچار خطا شود چه کسی و با چه فرایندی آن را پیگیری می‌کند؟

مدل درآمد را تعیین کنید

باید مشخص شود کسب‌وکار از چه طریقی درآمد ایجاد می‌کند. کارمزد معامله، برداشت یا خدمات دیگر می‌توانند بخشی از مدل درآمدی باشند، اما انتخاب آن‌ها فقط تصمیم مالی نیست و می‌تواند روی تجربه کاربر، رقابت‌پذیری و منطق حسابداری داخلی اثر بگذارد.

مسئولیت تیم‌ها را روشن کنید

راه‌اندازی صرافی صرفاً پروژه تیم برنامه‌نویسی نیست. باید مسئولیت حوزه‌هایی مانند موارد زیر مشخص باشد:

• عملیات مالی؛
• کنترل ریسک؛
• امنیت؛
• پشتیبانی؛
• بررسی حساب‌ها و موارد حساس؛
• نگهداری فنی؛
• رسیدگی به رخدادها؛
• رصد تغییرات مقررات.

جریان دارایی و درخواست‌ها را مستند کنید

مسیر یک واریز، سفارش یا برداشت را از ابتدا تا انتها بنویسید. مشخص کنید چه سیستم‌هایی درگیر می‌شوند، چه کنترل‌هایی اعمال می‌شوند، چه داده‌ای ثبت می‌شود و خطا در هر مرحله چگونه مدیریت خواهد شد.

هرچه این جریان قبل از برنامه‌نویسی روشن‌تر باشد، احتمال اینکه تیم فنی ناچار شود منطق کسب‌وکار را حدس بزند کمتر می‌شود.

مرحله ۴: بودجه و روش اجرای پروژه را تعیین کنید

بعد از مشخص‌شدن مدل و عملیات، برآورد مالی نیز معنای بیشتری پیدا می‌کند. هزینه صرافی را نمی‌توان فقط با تعداد صفحات سایت یا ظاهر پنل معاملاتی سنجید.

عواملی مانند این موارد می‌توانند روی بودجه اثر بگذارند:

• توسعه اختصاصی یا استفاده از زیرساخت آماده؛
• دامنه قابلیت‌های نسخه اولیه؛
• مدل اجرای معامله؛
• مدل کیف پول و نگهداری دارایی؛
• سطح امنیت؛
• احراز هویت و کنترل ریسک؛
• تأمین نقدینگی؛
• زیرساخت سرور و پایش؛
• آزمایش امنیتی و عملکردی؛
• پشتیبانی و عملیات پس از راه‌اندازی.

برای مثال، دو پلتفرم ممکن است از نظر ظاهری شبیه یکدیگر باشند، اما اگر یکی مسئول نگهداری دارایی کاربران، اتصال به چند تأمین‌کننده و اجرای کنترل‌های عملیاتی پیچیده باشد، هزینه و پیچیدگی آن را نمی‌توان با دیگری صرفاً براساس رابط کاربری مقایسه کرد.

پس از تعیین محدوده پروژه، برای بررسی عوامل مالی با جزئیات بیشتر می‌توانید سراغ مقاله هزینه ساخت صرافی ارز دیجیتال بروید. بهتر است موضوع هزینه در همان صفحه تخصصی بررسی شود تا این مقاله از نیت اصلی خود، یعنی توضیح مراحل راه‌اندازی، خارج نشود.

خروجی مرحله چهارم باید یک دامنه اجرایی واقعی باشد: بدانید نسخه اولیه چه چیزهایی دارد، چه منابعی می‌خواهد و کدام قابلیت‌ها می‌توانند به نسخه‌های بعدی منتقل شوند.

پیش از شروع توسعه فنی چه چیزهایی باید مشخص شده باشند؟

پیش از ورود جدی به ساخت محصول، یک کنترل «ادامه یا توقف» انجام دهید. این فهرست الزام رسمی یا چک‌لیست دریافت مجوز نیست؛ هدف آن جلوگیری از شروع زودهنگام توسعه است.

• مدل فعالیت دقیقاً مشخص است؟
• بازار و کاربران هدف معلوم‌اند؟
• وضعیت حقوقی مدل بررسی شده است؟
• ساختار حقوقی بهره‌بردار مشخص است؟
• تکلیف نگهداری دارایی کاربران روشن است؟
• مسیر ثبت‌نام، واریز، معامله و برداشت تعریف شده است؟
• KYC و کنترل ریسک در مدل عملیاتی دیده شده‌اند؟
• روش تأمین نقدینگی مشخص است؟
• محدوده نسخه اولیه تعیین شده است؟
• بودجه و منابع اجرای آن قابل تخمین هستند؟

اگر چند سؤال بنیادی هنوز پاسخ ندارند، توسعه ممکن است زود آغاز شده باشد.

برای نمونه، اگر هنوز معلوم نیست صرافی دارایی کاربران را چگونه نگهداری می‌کند، تصمیم درباره کیف پول، مدیریت کلید و سطح دسترسی‌ها نیز نمی‌تواند قطعی باشد. یا اگر روش نقدینگی مشخص نشده باشد، طراحی منطق اجرای سفارش بدون شناخت بازار واقعی ناقص می‌ماند.

عبور از این مرحله به این معنا نیست که تمام جزئیات پروژه حل شده‌اند؛ بلکه یعنی تیم فنی دیگر مجبور نیست مسائل بنیادی کسب‌وکار را هنگام ساخت محصول حدس بزند.

مرحله ۵: زیرساخت فنی صرافی را براساس نیاز واقعی انتخاب کنید

بعد از طی مراحل قبلی، نوبت زیرساخت فنی است. این جایگاه مهم است: ساخت نرم‌افزار فقط یک بخش از راه‌اندازی صرافی است، نه تمام آن.

بسته به مدل انتخاب‌شده، می‌توان توسعه اختصاصی، راهکار آماده یا ترکیبی از سرویس‌ها و اجزای اختصاصی را بررسی کرد. معیار انتخاب فقط سرعت ساخت نیست؛ کنترل زیرساخت، امنیت، قابلیت توسعه، هزینه نگهداری و میزان وابستگی به تأمین‌کننده نیز اهمیت دارند.

در مدل‌هایی که صرافی حساب و دارایی کاربران را مدیریت می‌کند، معمولاً باید درباره این اجزا تصمیم گرفته شود:

اجرای سفارش و معاملات

سیستم باید بداند سفارش چگونه ثبت، کنترل، تطبیق و تسویه می‌شود. این تصمیم باید با مدل نقدینگی هماهنگ باشد.

ثبت موجودی و عملیات داخلی

اگر موجودی کاربران داخل پلتفرم مدیریت می‌شود، سامانه به منطق دقیقی برای ثبت تغییر موجودی، کارمزد، رزرو دارایی و تسویه نیاز دارد.

کیف پول و ارتباط با شبکه‌ها

در صورت پشتیبانی از واریز و برداشت رمزارزی، نحوه مدیریت آدرس‌ها، تشخیص تراکنش، وضعیت شبکه و کنترل برداشت باید مشخص شود.

API و اتصال سرویس‌ها

احراز هویت، قیمت، نقدینگی، پیام‌رسانی، اپلیکیشن و سایر اجزا ممکن است از API استفاده کنند. OWASP در فهرست ریسک‌های API، مشکلاتی مانند ضعف احراز هویت، کنترل دسترسی ناکافی، مصرف کنترل‌نشده منابع و استفاده ناامن از APIهای ثالث را از ریسک‌های مهم معرفی می‌کند.

پنل عملیات

تیم‌های داخلی باید بتوانند عملیات حساس، وضعیت کاربران، خطاها و رخدادهایی را که نیازمند بررسی انسانی‌اند مدیریت کنند. سطح دسترسی به این پنل نیز باید براساس مسئولیت افراد محدود شود.

برای یک کسب‌وکار ایرانی، انتخاب تأمین‌کننده خارجی فقط مسئله کیفیت فنی نیست. پیش از وابستگی به سرویس KYC، نقدینگی، نگهداری دارایی، API یا زیرساخت خارجی، باید امکان استفاده توسط کسب‌وکار ایرانی، شرایط حساب، ریسک قطع دسترسی و مسیر جایگزین نیز بررسی شود.

خروجی این مرحله نباید فقط «سایت آماده» باشد؛ زیرساخت باید بتواند عملیات تعریف‌شده در مراحل قبلی را به‌شکل قابل کنترل اجرا کند.

برای طراحی و ارزیابی امنیت APIها نیز می‌توان OWASP API Security Top 10 – 2023 را به‌عنوان یکی از منابع فنی مرجع در نظر گرفت؛ این فهرست ریسک‌هایی مانند ضعف احراز هویت، ضعف کنترل دسترسی، مصرف کنترل‌نشده منابع و استفاده ناامن از APIهای ثالث را پوشش می‌دهد.

مرحله ۶: امنیت، کیف پول و نگهداری دارایی را طراحی کنید

امنیت صرافی نباید به تست نفوذ روزهای آخر محدود شود. معماری امنیت باید هم‌زمان با ساخت سیستم شکل بگیرد و بعد از راه‌اندازی نیز ادامه داشته باشد.

چارچوب امنیت سایبری NIST 2.0 مدیریت ریسک را در حوزه‌های حاکمیت، شناسایی، حفاظت، تشخیص، پاسخ و بازیابی سازمان‌دهی می‌کند. این نگاه نشان می‌دهد امنیت فقط جلوگیری از حمله نیست؛ سازمان باید بتواند رخداد را تشخیص دهد، به آن پاسخ دهد و سرویس را بازیابی کند.

مدل نگهداری دارایی را مشخص کنید

اگر کسب‌وکار دارایی کاربران را نگهداری می‌کند، باید دقیقاً روشن شود:

• کلیدهای حساس چگونه مدیریت می‌شوند؟
• چه کسانی به آن‌ها دسترسی دارند؟
• برداشت تحت چه کنترل‌هایی انجام می‌شود؟
• موجودی‌های داخلی چگونه با دارایی واقعی تطبیق داده می‌شوند؟
• در صورت به‌خطر افتادن یک کلید یا حساب چه اتفاقی می‌افتد؟
• برنامه بازیابی چیست؟

راهنمای مدیریت کلید NIST نیز مدیریت مواد کلیدی رمزنگاری را یک موضوع مستقل شامل حفاظت، دسترسی، چرخه عمر و سیاست‌های مدیریتی می‌داند.

به همین دلیل نمی‌توان بدون شناخت مدل پروژه یک نسبت ثابت و عمومی برای «کیف پول سرد» یا «کیف پول گرم» تعیین کرد و آن را برای همه صرافی‌ها مناسب دانست.

در بخش مدیریت کلیدهای رمزنگاری نیز NIST SP 800-57 Part 1 Rev. 5 مجموعه‌ای از اصول و بهترین رویه‌ها برای حفاظت و مدیریت مواد کلیدی رمزنگاری ارائه می‌کند.

دسترسی‌های حساس را محدود کنید

حساب مدیران، عملیات برداشت، تغییر تنظیمات امنیتی و دیگر اقدامات حساس باید کنترل بیشتری نسبت به حساب معمولی کاربر داشته باشند. استفاده از روش‌های احراز هویت مقاوم‌تر در برابر فیشینگ، تفکیک سطح دسترسی و ثبت اقدامات مدیریتی از کنترل‌های مهم در چنین محیطی هستند.

برای رخداد امنیتی از قبل برنامه داشته باشید

اگر حساب مدیریتی به خطر افتاد، سرویس ثالث قطع شد، برداشت غیرعادی شناسایی شد یا بخشی از زیرساخت از دسترس خارج شد، تیم نباید تازه در همان لحظه تصمیم بگیرد چه کاری انجام دهد.

NIST در راهنمای پاسخ به رخداد خود، آمادگی، تشخیص، پاسخ و بازیابی را بخشی از مدیریت مستمر ریسک سایبری می‌داند.

بنابراین امنیت در پایان این مرحله باید شامل پیشگیری، پایش و برنامه واکنش باشد.

برای ساختاردهی مدیریت ریسک امنیتی نیز چارچوب امنیت سایبری NIST 2.0 می‌تواند به‌عنوان یک مرجع عمومی استفاده شود؛ این چارچوب مدیریت ریسک سایبری را در حوزه‌هایی مانند حاکمیت، شناسایی، حفاظت، تشخیص، پاسخ و بازیابی سازمان‌دهی می‌کند.

مرحله ۷: KYC، AML و کنترل ریسک را عملیاتی کنید

در ایران، آیین‌نامه اجرایی مقابله و پیشگیری از جرایم پولشویی و تأمین مالی تروریسم، «دارایی مجازی» را تعریف کرده و خدماتی مانند تبدیل دارایی مجازی، انتقال و نگهداری یا مدیریت آن را نیز در مقررات مربوط پوشش داده است. بنابراین فرایندهای احراز هویت و کنترل ریسک باید متناسب با مقررات جاری و مدل واقعی فعالیت طراحی شوند.

احراز هویت فقط فرم گرفتن اطلاعات کاربر نیست. صرافی باید متناسب با خدمات و سطح ریسک خود بداند با چه فرد یا نهادی تعامل دارد و در برابر وضعیت‌های غیرعادی چه فرایندی اجرا می‌کند.

در مقررات تنقیحی مبارزه با پول‌شویی ایران، ارائه خدمات دارایی مجازی در دامنه مؤسسات مالی آمده و رویکرد مبتنی بر ریسک برای برنامه‌های داخلی مبارزه با پول‌شویی پیش‌بینی شده است. همچنین ارزیابی و طبقه‌بندی ریسک پیش از ارائه خدمت در این چارچوب اهمیت دارد.

در سال ۱۴۰۴ نیز دستورالعمل ساختار و تشکیلات مبارزه با پول‌شویی، ارائه‌دهندگان خدمات دارایی مجازی را در طبقه‌بندی مؤسسات مالی خود وارد کرده و برای سطوح مختلف، ساختارها و مسئولیت‌هایی در حوزه AML در نظر گرفته است.

در طراحی داخلی باید مشخص شود:

• چه اطلاعاتی هنگام ایجاد حساب لازم است؟
• چه سطحی از شناسایی برای هر خدمت نیاز است؟
• کاربران چگونه از نظر ریسک طبقه‌بندی می‌شوند؟
• چه شرایطی بررسی بیشتر را فعال می‌کند؟
• رفتار یا تراکنش غیرعادی چگونه بررسی می‌شود؟
• چه کسی مسئول رسیدگی به موارد حساس است؟
• سوابق موردنیاز چگونه نگهداری می‌شوند؟
• محدودسازی یک عملیات یا حساب با چه فرایندی انجام می‌شود؟

جزئیات این موارد باید از آخرین مقررات و مدل واقعی فعالیت استخراج شوند. کپی‌کردن فرم احراز هویت یک صرافی دیگر به این معنی نیست که مدل KYC و AML شما درست طراحی شده است.

همچنین باید بین استانداردهای بین‌المللی و الزامات حقوقی ایران تفکیک قائل شد. یک استاندارد خارجی ممکن است برای طراحی فرایند مفید باشد، اما تا زمانی که مبنای حقوقی داخلی مشخصی وجود ندارد، نباید با عنوان «الزام قانونی ایران» معرفی شود.

خروجی این مرحله باید یک فرایند عملیاتی باشد؛ یعنی تیم محصول، عملیات و کنترل ریسک بدانند در هر وضعیت چه کاری انجام می‌شود.

مرحله ۸: نقدینگی و مسیر واریز و برداشت را آماده کنید

داشتن موتور سفارش به‌تنهایی برای ایجاد بازار کافی نیست. اگر سفارش‌ها در قیمت و زمان قابل قبول اجرا نشوند، تجربه معاملاتی واقعی شکل نمی‌گیرد. به همین دلیل نقدینگی باید پیش از عرضه عمومی تعیین تکلیف شود.

نقدینگی و اجرای سفارش

باید مشخص شود سفارش‌ها در چه بازاری اجرا می‌شوند و عمق بازار چگونه تأمین خواهد شد.

پرسش‌های مهم عبارت‌اند از:

• کدام بازارها در نسخه اولیه فعال‌اند؟
• نقدینگی هر بازار از کجا تأمین می‌شود؟
• اگر منبع بیرونی قطع شود چه اتفاقی می‌افتد؟
• بازار کم‌عمق چگونه مدیریت می‌شود؟
• سفارش‌های باز هنگام اختلال چه وضعیتی پیدا می‌کنند؟
• چه زمانی معامله یک بازار باید محدود یا متوقف شود؟

تعداد بالای بازار معاملاتی لزوماً مزیت نیست. تعداد محدودتری از بازارهایی که نقدینگی و عملیات آن‌ها قابل پشتیبانی است می‌تواند انتخاب منطقی‌تری از فهرست بزرگی باشد که اجرای سفارش در آن قابل اتکا نیست.

اگر برای نقدینگی به سرویس خارجی وابسته هستید، همان ملاحظات دسترسی کسب‌وکار ایرانی، شرایط قرارداد، ریسک قطع سرویس و مسیر جایگزین باید پیش از وابستگی عملیاتی بررسی شوند.

واریز و برداشت

ورود و خروج پول و دارایی یکی از حساس‌ترین نقاط تجربه کاربر است. سیستم باید فقط حالت موفق را نشناسد.

برای واریز و برداشت رمزارزی باید وضعیت‌هایی مانند این موارد مدیریت شوند:

• تراکنش دیده شده اما تأیید کافی ندارد؛
• شبکه دچار اختلال است؛
• برداشت در انتظار بررسی است؛
• سرویس ثالث پاسخ نمی‌دهد؛
• درخواست ناموفق شده است؛
• تراکنش نیازمند پیگیری عملیاتی است.

در مسیرهای ریالی نیز نباید فرض شود یک بانک یا ارائه‌دهنده پرداخت مشخص برای همه مدل‌های کسب‌وکار و در همه زمان‌ها قابل استفاده است. امکان استفاده باید براساس شرایط روز، نوع فعالیت، قرارداد و مقررات مربوط بررسی شود.

هدف این مرحله آن است که مسیر عادی ورود، معامله و خروج دارایی قابل پیش‌بینی باشد و وضعیت‌های غیرعادی نیز فرایند مشخصی داشته باشند.

مرحله ۹: صرافی را قبل از عرضه عمومی آزمایش کنید

اولین آزمایش واقعی سیستم نباید با تعداد زیادی کاربر و دارایی واقعی انجام شود.

کل مسیر کاربر باید از ابتدا تا انتها آزمایش شود:

1. ایجاد حساب؛
2. احراز هویت؛
3. ورود؛
4. واریز؛
5. ثبت موجودی؛
6. ثبت سفارش؛
7. اجرای معامله؛
8. محاسبه کارمزد؛
9. درخواست برداشت؛
10. کنترل و انجام برداشت.

در کنار مسیر موفق، سناریوهای شکست نیز اهمیت دارند.

دسترسی‌ها را آزمایش کنید

کاربر نباید بتواند به اطلاعات یا عملیات کاربر دیگری دسترسی پیدا کند و کارکنان نیز نباید بیشتر از سطح موردنیاز خود اختیار داشته باشند. ضعف کنترل دسترسی و احراز هویت از ریسک‌های اصلی APIهای وب هستند.

خطاهای عملیات مالی را آزمایش کنید

برای شرایطی مانند درخواست تکراری، قطع ارتباط میان دو مرحله، خطای سرویس خارجی، برداشت معلق یا اختلاف موجودی باید وضعیت مشخصی وجود داشته باشد.

سامانه مالی خوب فقط زمانی که همه چیز درست کار می‌کند قابل اعتماد نیست؛ باید در زمان شکست نیز بتوان تشخیص داد چه اتفاقی افتاده و عملیات در چه وضعیتی قرار دارد.

واکنش به رخداد را آزمایش کنید

وجود سند پاسخ به رخداد کافی نیست. تیم باید بداند در زمان اختلال یا رخداد امنیتی چه کسی تصمیم می‌گیرد، چه عملیات‌هایی متوقف می‌شوند، چه اطلاعاتی بررسی می‌شوند و سرویس چگونه به وضعیت عادی بازمی‌گردد. این رویکرد با توصیه NIST برای ادغام پاسخ به رخداد در مدیریت ریسک سازگار است.

راه‌اندازی محدود با دامنه کنترل‌شده نیز می‌تواند روشی برای کشف مشکلات عملیاتی پیش از عرضه گسترده باشد، به شرط آنکه با مدل کسب‌وکار و الزامات پروژه سازگار باشد.

قبل از راه‌اندازی عمومی صرافی این موارد را کنترل کنید

پیش از عرضه عمومی، یک بار دیگر درباره ادامه یا توقف تصمیم بگیرید. این فهرست استاندارد رسمی صدور مجوز نیست؛ معیار عملی برای سنجش آمادگی پروژه است.

• وضعیت حقوقی مدل بررسی شده است.
• ساختار بهره‌بردار و مسئولیت‌ها مشخص‌اند.
• KYC و کنترل ریسک در محیط عملیاتی کار می‌کنند.
• واریز و برداشت از ابتدا تا انتها آزمایش شده‌اند.
• مدل نگهداری دارایی و مدیریت کلید روشن است.
• نقدینگی بازارهای فعال تأمین شده است.
• دسترسی‌های حساس کنترل شده‌اند.
• ثبت رویداد و پایش فعال است.
• پشتیبان‌گیری و بازیابی آزمایش شده‌اند.
• برنامه پاسخ به رخداد وجود دارد.
• تیم پشتیبانی و عملیات مسئولیت‌های مشخص دارند.
• خطاهای حیاتی شناخته‌شده پیش از عرضه رفع شده‌اند.

«نرم‌افزار آماده است» به‌تنهایی معیار کافی برای راه‌اندازی نیست.

ممکن است رابط کاربری کامل باشد، اما برداشت در شرایط خطا قابل پیگیری نباشد. شاید موتور معامله کار کند، اما بازار نقدینگی کافی نداشته باشد. یا کیف پول فعال باشد، اما برنامه مشخصی برای مدیریت کلید و واکنش به رخداد وجود نداشته باشد.

در هرکدام از این شرایط، تکمیل‌نشدن یک مرحله می‌تواند کل تجربه عملیاتی را تحت تأثیر قرار دهد.

مرحله ۱۰: بعد از راه‌اندازی، عملیات صرافی را دائماً پایش کنید

عرضه عمومی پایان پروژه نیست. از این نقطه، سیستم با رفتار واقعی کاربران، تغییرات بازار، درخواست‌های پشتیبانی، خطاهای پیش‌بینی‌نشده، حملات احتمالی و تغییر مقررات روبه‌رو می‌شود.

پایش باید حوزه‌هایی مانند این موارد را دربر بگیرد:

• سلامت زیرساخت؛
• خطاهای نرم‌افزاری؛
• عملکرد APIها؛
• وضعیت واریز و برداشت؛
• رخدادهای امنیتی؛
• رفتارهای غیرعادی؛
• کیفیت اجرای معامله؛
• وضعیت تأمین‌کنندگان؛
• ظرفیت سامانه؛
• تیکت‌ها و مشکلات پرتکرار کاربران.

چارچوب NIST نیز امنیت را فعالیتی مستمر می‌بیند که شناسایی، حفاظت، تشخیص، پاسخ و بازیابی را در چرخه مدیریت ریسک به هم متصل می‌کند.

مقررات نیز باید پایش شوند. نسخه تنقیحی مقررات AML ایران بر برنامه‌های داخلی مبتنی بر ریسک تأکید دارد و دستورالعمل‌های این حوزه می‌توانند ساختار و مسئولیت‌های داخلی مؤسسات مالی را تحت تأثیر قرار دهند.

آموزش کاربر را بخشی از عملیات ببینید

کاربر صرافی با موضوعاتی مانند احراز هویت، انتخاب شبکه انتقال، امنیت حساب، وضعیت واریز و برداشت و کار با سرویس‌های مالی روبه‌رو است. اگر برای این موضوعات راهنمای دقیق وجود نداشته باشد، بخشی از ابهام‌های قابل پیشگیری مستقیماً به تیم پشتیبانی منتقل می‌شوند.

بنابراین محتوای تخصصی می‌تواند بخشی از زیرساخت آموزش و اعتمادسازی یک کسب‌وکار رمزارزی باشد. برای تیمی که ظرفیت تولید مستمر ندارد، استفاده از محتوای آماده ارز دیجیتال زمانی منطقی است که مطالب انتخاب‌شده با خدمات واقعی، مخاطب، لحن برند و اطلاعات به‌روز همان کسب‌وکار سازگار باشند؛ انتشار محتوای عمومی و بی‌ارتباط صرفاً برای پرکردن وبلاگ چنین ارزشی ایجاد نمی‌کند.

در عمل، صرافی محصولی نیست که یک بار ساخته و سپس رها شود. امنیت، عملیات، محتوا، پشتیبانی، کنترل ریسک و فناوری باید همراه با تغییر بازار، مقررات و رفتار کاربران توسعه پیدا کنند.

اشتباهاتی که مسیر راه‌اندازی صرافی را پرریسک می‌کنند

برخی خطاها از انتخاب فناوری نامناسب ایجاد نمی‌شوند؛ مشکل اصلی این است که تصمیم درست در زمان نادرست گرفته شده است.

شروع برنامه‌نویسی قبل از مشخص‌شدن مدل فعالیت

اگر هنوز معلوم نیست چه خدماتی ارائه می‌شوند، بازار هدف چیست و مسئولیت نگهداری دارایی با چه کسی است، توسعه روی مجموعه‌ای از فرضیات آغاز می‌شود. تغییر یکی از این فرضیات می‌تواند بخش‌هایی از محصول را نیازمند بازطراحی کند.

یکی دانستن ساخت نرم‌افزار با راه‌اندازی صرافی

ممکن است یک پلتفرم از نظر فنی قابل استفاده باشد، اما مدل نقدینگی، کنترل ریسک، عملیات برداشت یا پاسخ به رخداد آماده نباشند. ساخت نرم‌افزار فقط یکی از مراحل پروژه است.

برآورد هزینه پیش از تعریف محدوده

عدد هزینه تا زمانی که مدل، قابلیت‌ها، امنیت، معماری و سطح عملیات مشخص نشده‌اند ارزش محدودی دارد. دو پیشنهاد که هر دو با عنوان «ساخت صرافی» ارائه می‌شوند ممکن است در عمل دو پروژه کاملاً متفاوت باشند.

موکول‌کردن امنیت به آخر پروژه

اگر مدیریت کلید، کنترل دسترسی، ثبت رخداد و معماری حفاظتی در پایان اضافه شوند، بعضی اصلاحات ممکن است نیازمند تغییر بخش‌های بنیادی سیستم باشند. امنیت باید از طراحی وارد پروژه شود.

نادیده‌گرفتن مدیریت کلید

داشتن کیف پول به‌تنهایی پاسخ مسئله نگهداری دارایی نیست. باید مشخص باشد کلیدها چگونه محافظت می‌شوند، چه کسانی اجازه استفاده از آن‌ها را دارند و در صورت به‌خطر افتادن دسترسی چه اتفاقی می‌افتد. راهنماهای NIST نیز مدیریت کلید را یک حوزه مستقل امنیتی می‌دانند.

راه‌اندازی بازار بدون نقدینگی کافی

اضافه‌کردن تعداد زیادی بازار معاملاتی بدون مدل نقدینگی مشخص می‌تواند سفارش‌هایی با اجرای ضعیف ایجاد کند. نقدینگی باید پیش از عرضه هر بازار تعیین تکلیف شود.

آزمایش‌نکردن سناریوهای شکست

تست فقط نباید نشان دهد که کاربر می‌تواند در شرایط عادی معامله کند. خطای API، قطع سرویس، درخواست تکراری، برداشت معلق و اختلاف موجودی نیز باید وضعیت تعریف‌شده داشته باشند.

فراموش‌کردن عملیات پس از عرضه

اگر برنامه پروژه در روز افتتاح تمام شود، بخش بزرگی از کسب‌وکار نادیده گرفته شده است. پشتیبانی، نگهداری، امنیت، کنترل ریسک، رصد مقررات و پاسخ به رخداد فعالیت‌های مداوم‌اند.

سخن پایانی

در نحوه راه اندازی صرافی ارز دیجیتال، مهم‌ترین اصل این است که توسعه نرم‌افزار تنها یک حلقه از زنجیره راه‌اندازی است. مدل فعالیت، وضعیت حقوقی، عملیات، بودجه، امنیت، نگهداری دارایی، KYC، نقدینگی و تست باید در ترتیب منطقی خود تعیین تکلیف شوند تا تصمیم ناقص یک مرحله، مراحل بعدی را مجبور به بازطراحی نکند.

پیش از شروع توسعه، ابهام‌های بنیادی را برطرف کنید و پیش از عرضه عمومی نیز فقط به آماده‌بودن رابط کاربری و قابلیت‌های نرم‌افزار اکتفا نکنید. زمانی وارد فعالیت عمومی شوید که عملیات واقعی، کنترل ریسک، حفاظت از دارایی، نقدینگی و برنامه مواجهه با خطا نیز آماده باشند.

سؤالات متداول

۱. آیا برای راه‌اندازی صرافی ارز دیجیتال در ایران مجوز لازم است؟

نباید فعالیت این حوزه را بدون بررسی مقررات روز، «بدون نیاز به مجوز یا نظارت» فرض کرد. قانون بانک مرکزی تصمیم‌گیری درباره جواز یا عدم جواز نگهداری و مبادله انواع رمزپول را در چهارچوب قانون در حوزه هیأت عالی بانک مرکزی قرار داده و مقررات AML نیز خدمات دارایی مجازی را صریحاً پوشش می‌دهند. نوع مجوز، الزامات و فرایند قابل اجرا باید متناسب با مدل فعالیت از آخرین منابع رسمی بررسی شود.

۲. آیا برای راه‌اندازی صرافی باید پلتفرم را از صفر برنامه‌نویسی کرد؟

خیر. توسعه کاملاً اختصاصی فقط یکی از مسیرهای ممکن است. بسته به مدل فعالیت، بودجه، سطح کنترل موردنیاز، امنیت، قابلیت توسعه و شرایط استفاده از تأمین‌کنندگان، می‌توان از توسعه اختصاصی، راهکارهای آماده یا ترکیبی از آن‌ها استفاده کرد. انتخاب مسیر فنی باید بعد از مشخص‌شدن نیازهای کسب‌وکار انجام شود.

۳. تفاوت راه‌اندازی صرافی با ساخت سایت صرافی چیست؟

ساخت سایت یا پلتفرم بخش فنی پروژه است؛ راه‌اندازی صرافی مفهوم گسترده‌تری دارد و مدل کسب‌وکار، الزامات حقوقی، عملیات، نگهداری دارایی، امنیت، KYC و AML، نقدینگی، واریز و برداشت، آزمایش، پشتیبانی و مدیریت مستمر را نیز شامل می‌شود.