در 11 مارس 2016 ، به عنوان بخشی از مشاوره های خود در مورد اقدامات سطح 2 تحت مقررات مربوط به تأمین اعتبار اوراق بهادار (SFTR) ، اوراق بهادار و مرجع بازار اروپا (ESMA) مقاله بحثی را منتشر کرد که شامل پیش نویس استانداردهای فنی نظارتی (RTS) و اجرای استانداردهای فنی (اجرای استانداردهای فنی) (RTS) و اجرای استانداردهای فنی (RTS) و اجرای استانداردهای فنی (RTS) و اجرای استانداردهای فنی (RTS))آن) در گزارش معاملات تحت SFTR.
در 187 صفحه و مطرح کردن 145 سؤال ، مقاله بحث و گفتگو فاقد سرعت است و در بیشتر موارد ، به جزئیات فنی می پردازد. این سه موضوع اصلی را در بر می گیرد:
- ثبت نام به عنوان مخزن تجاری (TR) ؛
- گزارش نویسی؛وت
- شفافیت و در دسترس بودن داده ها.
خلاصه ای از مقاله بحث در زیر آورده شده است.
ثبت نام به عنوان یک مخزن تجاری
طبق ماده 5 SFTR ، ESMA موظف است RTS و آن را در مورد ثبت TRS به منظور گزارش معاملات تأمین مالی اوراق بهادار (SFT) تحت SFTR تهیه کند. ESMA معتقد است که RTS باید تا حد امکان ، RTS 150/2013 را تکرار کند[1](Emir tr rts) ، با اصلاحاتی برای موضوعات خاص SFTR و پیشرفت های آموخته شده از گزارش تجارت Emir. در این زمینه ، جزئیات بیشتری از TRS به مکانیسم های کنترل داخلی [2] ، زنده ماندن تجاری [3] ، ترتیبات برون سپاری [4] ، استقلال عملیاتی [5] ، ریسک عملیاتی و برنامه ریزی تداوم تجارت مورد نیاز خواهد بود.
مقررات جدید نیز به منظور رعایت الزام TRS برای ایجاد رویه هایی برای تأیید کامل و صحت ارسال داده های SFT ، از جمله:
- احراز هویت کاربران ؛
- اعتبار گزارش ارسالی ؛
- تأیید مجوز طرف گزارش دهنده برای ارسال داده ها به نمایندگی از سایر نهادها.
- اعتبار سنجی منطقی (یعنی اطمینان از اینکه داده های مربوط به SFT های گزارش نشده/لغو شده اصلاح نشده است).
- اعتبار سنجی محتوا ؛
- آشتی داده های بین TR ؛وت
- بازخورد به موقع به شرکت کنندگان در مورد گزارش ارسال ها (به عنوان مثال در صورت پذیرش یا رد (و چرا)).
TRS نیز لازم خواهد بود:
- حداقل یک شخص مناسب را تعیین کنید که مسئولیت آن را بر عهده بگیرد.
- توضیحات مفصلی از سیستم مورد استفاده برای گزارش SFT ارائه می دهد.
- شواهدی مبنی بر اینکه آنها از ماده 12 (3) (د) SFTR استفاده کرده اند (که مقامات را ملزم به دسترسی مستقیم و فوری به داده های موجود در TRS می کند) [7] ؛
- در صورت خروج از مجوز TR آنها ، مراحل مربوط به انتقال داده های SFT را نشان می دهد [8] ؛وت
- شواهدی از اقداماتی که آنها برای محافظت در برابر حملات سایبری برداشته اند [9].
گزارش نویسی
عمومی
ESMA با تکیه بر تجربیات EMIR خود اذعان می‌کند که «قوانین کاملاً جامع و بدون ابهام در مورد قالب‌های اطلاعات برای گزارش‌دهی ضروری هستند». علاوه بر این، «چنین قوانینی نباید تنها به استانداردهای داده مربوطه، طول فیلدها و مقادیر مجاز محدود شود، بلکه باید یک قالب فنی و الگوی مشترکی را مشخص کند که در آن اطلاعات باید به TRs ارائه شود».[10]به منظور محدود کردن هزینه‌های عملیاتی، فرمت‌های گزارش‌دهی با چارچوب‌های موجود مانند چارچوب‌های موجود در MiFIR، مقررات سوءاستفاده از بازار[11]، EMIR و مقررات گزارش‌دهی آماری بازار پول[12] همسو خواهند شد و بر اساس قالب فنی ISO 20022 خواهند بود. 13] با استفاده از یک طرح XML مشترک.
منطق گزارشگری
گزارش رویدادهای تجاری و چرخه حیات
ESMA دو رویکرد را برای گزارش رویدادهای تجاری و چرخه عمر SFT در نظر می گیرد:
- یک رویکرد سازگار با EMIR؛و
- یک رویداد تجاری ترکیبی و رویکرد اقدام فنی.
«رویکرد سازگار با EMIR» همان «انواع اقدام» مورد استفاده در گزارش‌های تجاری EMIR را با دو افزوده («قیمت مجدد» و «افزایش اصلی») و یک اصلاحیه که نوع اقدام «به‌روزرسانی وثیقه» را معرفی می‌کند، اتخاذ می‌کند. نوع اقدام EMIR "Compression"، "Valuation Update" و "Position Component" (زیرا در حال حاضر مشخص نیست که آیا لازم است SFT ها در سطح موقعیت گزارش شوند یا خیر).
رویکرد "ترکیبی" 7 "نوع رویداد" را تعریف می کند:
| · Repo / رویداد تجاری را معکوس می کند | · خرید و فروش مجدد رویداد تجارت |
| · رویداد تجاری قرض و وام | · رویداد تجاری وام حاشیه |
| · رویداد چرخه عمر تنظیم برای وثیقه، پول نقد یا هر دو | · رویداد چرخه حیات خاتمه یافتن |
| · قیمت گذاری مجدد چرخه عمر |
چهار "اقدام فنی" می توانند برای هر "نوع رویداد" مشخص شوند، که عبارتند از:
| · جدید | · تغییر | · تصحیح | · لغو. |
ESMA در مورد مزایا و معایب مرتبط با هر رویکرد بازخورد درخواست می کند.
شناسایی «خریدار» و «فروشنده»
مطابق با EMIR، ESMA پیشنهاد می‌کند یک فیلد «سمت طرف مقابل» معرفی شود که نشان می‌دهد طرف مقابل در رابطه با SFT زیربنایی «خریدار» یا «فروشنده» است. همچنین راهنمایی در مورد شناسایی خریدار یا فروشنده بسته به نوع معامله را پیشنهاد می کند[14].
سایر مسائل
در میان سایر مسائل منطقی گزارش، مقاله بحث:
- روشن می کند که تعریف "SFT" به پوشش گسترش می یابدناامنمعاملات وام دهی اوراق بهادار[15];
- درخواست بازخورد در مورد نحوه گزارش معاملات وام حاشیه و معاملات تامین مالی کالا (و کالاهای اساسی را می توان شناسایی کرد[16]). و
- به دنبال شفاف سازی در مورد نقش عوامل سه حزبی است.
محتوا و ساختار گزارش های SFT
ESMA تقسیم داده های SFT را به دو دسته پیشنهاد می کند - "داده های طرف مقابل" و "داده های تراکنش". این با EMIR مطابقت دارد، جایی که داده ها به «داده های طرف مقابل» و «داده های مشترک» (که به تراکنش ها مربوط می شود) گروه بندی می شوند. در مورد پیشنهادهایی که شامل تعدادی از فیلدهای داده خاص، از جمله:
- شناسایی شعبه[17] از طریق استفاده ترکیبی از کدهای LEI و ISO (یک جدول مفید راهنمایی در مورد زمانی که یک تراکنش SFT-مانند شامل یک یا چند شعبه یک SFT قابل گزارش ایجاد می‌کند، ارائه می‌کند).
- شناسایی «ذینفع SFT» (یعنی طرف - که لزوماً طرفی نیست که SFT را اجرا کرده است - که مشمول حقوق و تعهدات ناشی از قرارداد است).
- پیوند دادن گزارش‌های مختلف SFT توسط یک شناسه مشترک به‌گونه‌ای که بتوان آن تراکنش را در طول زمان ردیابی کرد (به عنوان مثال اگر یک معامله دوجانبه متعاقباً تسویه شود، برای متمایز کردن نقش‌هایی که معامله‌گران اصلی در بازار repo ایفا می‌کنند و کمک به اطمینان از داده‌های اساسیکیفیت)؛و
- گزارش وثیقه (و استفاده مجدد از وثیقه) از نظر:
- «تخصیص وثیقه مبتنی بر تجارت» [19] در مقابل «تخصیص وثیقه بر اساس قرارگیری خالص» [20]؛
- «تخصیص وثیقه با تاریخ تجارت» [21] در مقابل «تخصیص وثیقه به تاریخ ارزش» [22]؛و
- عناصر وثیقه ای که باید گزارش شود، با ارجاع به موارد زیر تقسیم می شود:
- وثیقه نقدی؛
- وثیقه اوراق بهادار یا کالا؛
- استخرهای وثیقه; و
- مارجین وام؛
- اینکه آیا یک تراکنش به صورت متمرکز تسویه شده است یا خیر.
- هویت CCP مربوطه و عضو تسویه حساب؛و
- مهر زمانی پاکسازی
- هویت هر سپرده گذاری مرکزی اوراق بهادار؛
- هر "شرکت کننده مستقیم یا غیرمستقیم" که SFT را تسویه می کند.
- هر «داخلی ساز تسویه حساب»؛
- "محل استقرار"؛
- تلفن؛
- سیستم معاملاتی خودکار (یعنی سیستم‌هایی که در آن تراکنش‌ها نمی‌توانند انجام شوند و تسویه حساب نمی‌تواند شروع یا تکمیل شود). و
- سیستم‌های معاملاتی خودکار (یعنی سیستم‌هایی که می‌توان در آن تراکنش‌ها را انجام داد و تسویه حساب را شروع و تکمیل کرد).
خود فیلدهای داده به مقاله بحث پیوست شده است. آنها رویکردی موازی با گزارش تراکنش EMIR، با تغییرات آشکار برای در نظر گرفتن تراکنش های مختلف اساسی اتخاذ می کنند. علاوه بر این، طبقه‌بندی کالاها بر اساس «محصول پایه»، «محصول فرعی» و «محصول فرعی بیشتر» ارائه شده است.
شفافیت و در دسترس بودن داده ها
استانداردهای عملیاتی برای جمع آوری داده ها
ESMA تعدادی قواعد عملی را برای جمع‌آوری داده‌ها پیشنهاد کرده است تا اطمینان حاصل شود که TRها می‌توانند از الزامات ایجاد رویه‌هایی برای «تأیید کامل و صحت جزئیات گزارش‌شده به آنها» پیروی کنند[23]. پیشنهادات به دسته های زیر تقسیم می شوند:
- اعتبارسنجی، از جمله:
- احراز هویت شرکت کنندگان؛
- اعتبار سنجی طرحواره (بر خلاف استاندارد گزارش دهی ISO 20022 برای SFTها)؛
- شواهدی مبنی بر مجوز از نهادی که گزارش ها از طرف آن ارائه می شود.
- اعتبار سنجی منطقی (به عنوان مثال برای اطمینان از اینکه یک گزارش سعی در اصلاح یک SFT وجود ندارد/لغو شده ندارد)؛و
- قوانین کسب و کار / اعتبار سنجی محتوا.
- تطبیق بین TR و بین TR (حداقل) همه «فیلدهای داده مشترک» که باید در t+1، با استفاده از قالب‌ها و روشهای سازگار، با اطلاع‌رسانی مقادیر متضاد به طرف‌های مربوطه در همان روز انجام شود.
- تطبیق داده های وثیقه که باید جدا از تطبیق داده های SFT انجام شود ("داده های وام").
- نشان دادن، ظرف یک ساعت پس از ارسال، اینکه آیا ارسال توسط یک TR پذیرفته یا رد شده است (و در صورت رد، مبنای رد).
- تأیید، برای همه ارسال‌های پذیرفته‌شده، اینکه آیا یک SFT مطابقت دارد یا نه (تا پایان روزی که در آن آشتی انجام می‌شود).
- ارائه حداقل مجموعه ای از گزارش های بازخورد با جزئیات:
- فعالیت روزانه؛
- وضعیت تجارت؛
- ردها؛و
- وضعیت آشتی
داده های عمومی
بند 1 ماده 12 SFTR مقرر می‌دارد: «یک مخزن تجارت باید به‌طور منظم و به روشی آسان، مجموع موقعیت‌ها را بر اساس نوع SFTهایی که به آن گزارش می‌شوند منتشر کند.»این الزام اساساً مشابه الزامات موجود در EMIR است که به دلیل سطح بالا، منجر به ایجاد داده های عمومی استاندارد نشده است. ESMA در مورد اینکه آیا رویکرد دقیق‌تر به داده‌های عمومی - اما رویکردی که هنوز امکان شناسایی طرف‌های متقابل منفرد را نمی‌دهد - برای افزایش ارزش آن برای عموم مردم مناسب است یا خیر، نظر می‌خواهد.
داده هایی که در اختیار مقامات قرار گرفته است
ماده 12 (2) SFTR به TRS نیاز دارد تا اطمینان حاصل شود که برخی از مقامات نظارتی دسترسی مستقیم و فوری به داده های SFT دارند. داده ها باید در اسرع وقت و حداکثر 7 ساعت پس از ارسال به TR توسط همتایان به SFT در دسترس باشند. TRS نباید به دلیل هرگونه روند آشتی در حال انجام ، داده ها را به مقامات تأخیر کند. اطلاعات باید در همان فرمت ISO 20022 ارائه شود زیرا دریافت می شود و باید کلیه عناصر داده ارسال شده توسط طرفین گزارش دهی را همراه با زمینه های اضافی که در زیر مشخص شده است ، تشکیل دهد:
- اطلاعات مربوط به وضعیت آشتی هر SFT (احتمالاً افزایش یافته است که شامل وضعیت آشتی وثیقه مرتبط باشد). وت
- این که آیا ارسال SFT قبل از پذیرش آن توسط TR رد شده است یا خیر.
هنگام دسترسی به تنظیم کننده ها ، پیشنهاد می شود که TRS اطمینان حاصل کند که حداقل ، انواع گزارش های زیر به مقامات ارائه می شود:
- گزارش های سطح معامله:
- تمام ارسال های SFT که در روز کاری قبلی انجام شده است.
- آخرین وضعیت SFT های برجسته از نزدیک به روز کاری قبلی ؛
- کلیه ارسال های SFT مطابق با هر معیاری که توسط مرجع مشخص شده است (برای تولید همان روز).
- گزارش روزانه جزئیات همه SFT های رد شده و دلایل رد. وت
- گزارش روزانه جزئیات وضعیت آشتی کلیه SFT های پذیرفته شده و دلایل عدم آشتی.
- قرار گرفتن در معرض ناخالص و خالص بین همتایان ؛
- صلاحیت همکار گزارشگری ؛
- صلاحیت طرف مقابل دیگر ؛
- بخش طرف مقابل ؛
- نوع SFT (repo ، وام اوراق بهادار و غیره) ؛
- نشانه ای از پاک شدن یا نه ؛
- نوع کلاس دارایی وثیقه (پول نقد ، سهام ، اوراق بهادار شرکت ، اوراق قرضه دولتی و غیره) ؛
- ارز پای نقدی ؛
- سطل بلوغ ؛وت
- مدل مو اعمال شده است.
سایر موارد و مراحل بعدی
ماده 13 و 14 SFTR به UCIT ها و AIFM ها نیاز دارد تا از قبل قرارداد و افشای دوره ای برای سرمایه گذاران ارائه دهند و اطلاعاتی را که باید در ضمیمه A و ضمیمه B SFTR ارائه شود ، ارائه دهد. SFTR همچنین به ESMA قدرت می دهد تا استانداردهای فنی نظارتی را پیش بینی کند که محتوای آن ضمیمه ها را بیشتر مشخص کند. با این حال ، ESMA احساس می کند که این "بهترین رویکرد در این مرحله" نخواهد بود. علاوه بر این ، ESMA در مرحله بعدی در مورد مورد مورد نیاز خود در ماده 25 SFTR در مورد تبادل اطلاعات بین مقامات ذیصلاح و ESMA در رابطه با تحریم های تحمیل شده به بنگاه ها برای نقض SFTR مشورت خواهد کرد.
دوره بحث تا 22 آوریل 2016 باز است. پس از آن ، ESMA انتظار دارد مقاله مشاوره را در اوایل Q3 2016 منتشر کند. فقط یک دور مشاوره وجود خواهد داشت [24]. پس از آن ، گزارش نهایی و پیش نویس استانداردهای فنی تا 13 ژانویه 2017 به کمیسیون اتحادیه اروپا ارسال می شود.
نتیجه
تجربه EMIR نیاز روشنی را برای تعریف جزئیات و محتوای داده هایی که باید به آنها گزارش شود ، نشان داده و توسط TRS در دسترس قرار داده است. تحت SFTR ، بیش از 100 مقام به داده های SFT گزارش شده به TRS دسترسی خواهند داشت و بر لزوم استاندارد سازی تأکید می کنند. در انصاف ، به نظر می رسد ESMA این را درک کرده است. مطمئناً ، فرمی که در آن اطلاعات ارائه می شود بسیار تجویز می شود تا تحت عنوان Emir - یک توسعه خوش آمدید. به طور کلی ، مطالب مقاله بحث و گفتگو اولین گام خوب در جهت ساختن یک چارچوب گزارشگری قوی است.
با این حال ، ماهیت تسریع شده روند مشاوره بیشتر تأسف آور است. اگر امیر به صنعت آموخته باشد ، این نیست که با بهترین خواست در جهان ، گزارش معاملات (به ویژه گزارش معاملات 2 طرفه) بسیار پیچیده است و از این رو اشتباه بسیار آسان است. نتیجه - همانطور که با امیر مشاهده می شود - ممکن است این باشد که بازسازی رژیم به ترتیب نسبتاً کوتاه می تواند ضروری شود. اگرچه بعید است که قوانین گزارشگری SFTR تا حدود Q3 2018 اجرا شود ، اما تجربه Emir همچنین نشان می دهد که این یک زمان طولانی برای یک تمرین از این بزرگی نیست. ESMA تا حد زیادی از مسئولیت این جبهه خلاص می شود زیرا بازه زمانی نظارتی به خود SFTR سخت می شود. با این وجود ، این قطار اکنون از ایستگاه خارج می شود. اگر بازار بخواهد دیدگاه های خود را مشخص کند ، اکنون باید سوار شود.
[1] کدام یک از روند درخواست ثبت نام را به عنوان TR تحت EMIR شرح می دهد
[2] به بند 43 مراجعه کنید. در حال حاضر فقط یک "نمای کلی" طبق ماده 7 TR RTS مورد نیاز است
[3] به بند 44 مراجعه کنید
[4] به بند 45 مراجعه کنید
[5] به بند 46 مراجعه کنید
[6] به بند 49-50 مراجعه کنید
[7] به بند 61-62 مراجعه کنید
[8] به بند 64 مراجعه کنید
[9] به بند 65 مراجعه کنید
[10] به بند 73 مراجعه کنید
[11] مقررات (اتحادیه اروپا) شماره 596/2014
[12] مقررات (اتحادیه اروپا) شماره 1333/2014
[13] به بند 90 مراجعه کنید
[14] به بند 140 مراجعه کنید
[15] به بند 167 مراجعه کنید
[16] احتمالاً از طریق استفاده از isin
[17] همانطور که در ماده 2 (1) (الف) SFTR لازم است
[19] جایی که وثیقه صریحاً با یک SFT خاص مرتبط است ، و در نتیجه یک رابطه یک به یک یا یک به یک بین تجارت و وثیقه ایجاد می شود
[20] در جایی که رابطه بسیاری به یک یا بسیاری از آنها بین معاملات و وثیقه وجود دارد
[21] در جایی که هر دو طرف مقابل با وثیقه SFT در زمان اجرای آن موافقت کرده اند ، اجازه می دهد اوراق بهادار صریح مورد استفاده به عنوان وثیقه در T+1 گزارش شود
[22] در جایی که وثیقه در تاریخ ارزش پای SFT به SFT اختصاص داده می شود ، به این معنی که ممکن است گزارش اوراق بهادار صریح مورد استفاده به عنوان وثیقه توسط T+1 امکان پذیر نباشد
