שירות מקיף לעיצוב משפטי, להכנת מסמכים ולמפת דרכים להשקה עבור השקת מערכת תשלומים באיחוד האירופי.
השירות מתאים ל-processing, לתשלומים מסחריים, לפayout, לעיבוד תשלומים (acquiring), לארנק אלקטרוני ולמוצרי תשלום אחרים שיוצאים לשוק האיחוד האירופי.
ההשקה המשפטית של מערכת תשלומים באיחוד האירופי - היא לא רק אפשרות משפטית נפרדת, אלא אריזה משפטית של שירות תשלומים, שנדרשת כאשר חברה רוצה להיכנס לשוק באמצעות מודל ברור, ניתן לאימות ומנוהל. שירות זה מועיל במיוחד למייסדים של פרויקטי פינטק מפוקחים, לפלטפורמות קיימות שרוצות לעבור ממודל שותפות לרישיון משלהן, וכן לחברות שמכינות השקה באיחוד האירופי ורוצות להבין מראש את היקף הדרישות בפועל. בפינטק ובתחומים רגולטוריים סמוכים כמעט תמיד לא מספיק "לרשום חברה" או "להכין טופס". צריך לחבר יחד מבנה תאגידי, שרשרת חוזית, תרחישים של מוצר, קומפליינס, תשתית תשלומים, אתר והפצה בפועל של תפקידים בתוך העסק.
בסיס נורמטיבי. בפרויקטים של תשלומים וארנקים אלקטרוניים ב-האיחוד האירופי נקודת המוצא בדרך כלל הן דרישות PSD2 - ההוראה (EU) 2015/2366 בנושא שירותי תשלום בשוק הפנימי. גם כאשר הפרויקט נבנה באמצעות שותפות עם ספק מורשה פעיל, המסמכים, זרימות המשתמשים, חלוקת התפקידים והטקסטים באתר חייבים להתאים למודל המשפטי בפועל; אחרת עולים שאלות בפני בנקים, שותפי עיבוד ורגולטור.
למי ולמה נחוצה השירות הזה. בדרך כלל, להפעלה משפטית של מערכת תשלומים ב-EU פונים בארבעה מצבים טיפוסיים. הראשון - הפרויקט נמצא בשלב הרעיון או ה-MVP ורוצה להבין עוד לפני פיתוח ומשא ומתן עם בנקים איזו מודל בכלל בר-קיימא. השני - החברה כבר התחילה לעבוד דרך שותפים, אבל רוצה לעבור לרישיון משלה או למסגרת רגולטורית משלה. השלישי - לצוות יש מוצר, אתר ומצגת למשקיעים, אבל אין קונסטרוקציה משפטית מתואמת, וכתוצאה מכך כל שותף חדש מתחיל לשאול שאלות לא נוחות. הרביעי - צריך להתכונן לדיאלוג עם הרגולטור, הבנק, שותף העיבוד, רואה החשבון או המשקיע כך שהמסמכים לא יתנגשו עם מודל התפעול האמיתי.
מדוע חשוב לעשות זאת נכון כבר מההתחלה. סיכונים אופייניים כאן הם סיווג שגוי של השירות, קונפליקט בין תיאור השיווקי של המוצר לבין הנתיב האמיתי של הלקוח, מבנה תאגידי לא מתאים, מדיניות פנימית ומסמכים חלשים, שבגללם הפרויקט נתקע בשלב הבנק, PSP, auditor או רישוי. בפועל, שגיאות לעיתים רחוקות נראות כמו "דחייה גלויה מסיבה אחת". לרוב הן מצטברות: בנתיב של המשתמש כתוב דבר אחד, בתנאי השירות - משהו אחר, בחוזה מול השותף - שלישי, ובמצגת לבנק - רביעי. כתוצאה מכך הפרויקט מאבד חודשים על התאמה מחדש של חומרים שכבר מוכנים, משנה את המבנה אחרי ההתאגדות, כותב מחדש את ה-onboarding, משנה תעריפים או דוחה את ההשקה. בדיוק לכן השירות בכיוון "Legal Launch של מערכת תשלומים באיחוד האירופי" נדרש לא בשביל חבילת משפטית יפה, אלא כדי לבנות מודל עובד שאפשר באמת להוציא לשוק.
מה בדיוק נבנה במסגרת השירות. השירות מתאים ל-processing, לתשלומי סחר, לתשלומי payout, לסליקת כרטיסים, לארנק אלקטרוני ולמוצרי תשלום אחרים שיוצאים לשוק האיחוד האירופי. חשוב שהרכב העבודה לא יתקיים בנפרד מהעסק: כל מדיניות, כל הסכם וכל תיאור של תהליך חייבים לתת מענה לשאלות מעשיות - מי הוא ספק השירות, היכן נולדות זכויות וחובות הלקוח, מי שומר כספים או נכסים, מי מבצע KYC, כיצד מטופלות תלונות, מי אחראי על ניהול אירועים וכיצד יוסדר לאחר הפעלת ה-compliance.
השירות נחוץ במיוחד לחברות שמקבלות תשלומים, שולחות העברות, מארגנות תשלומים, מבצעות סליקה (acquiring), מבצעות התחשבנויות מול סוחרים או כל זרם תשלומים אחר באזור "אירופה". כאן קריטי לא לערבב את הפונקציה הטכנולוגית עם פעילות מוסדרת ולא לשלב במוצר מודל שגוי.
אם העסק העיקרי שלך לא היה פיננסי מלכתחילה, אבל אתה רוצה לשלב גביית כספים, תשלומים, התחשבנויות מול משתמשים, ניכוי עמלה ואינטגרציות עם בנקים-השירות הזה עוזר להבין איפה עובר הגבול בין תפקיד פלטפורמלי מותר לבין פונקציה הנדרשת ברישוי.
בלוק זה שימושי במיוחד עבור מי שבמסגרת העסק אוסף חוזים מול בנקים ושותפי עיבוד, טקסטים באתר, מסע הלקוח, טיפול בתלונות, AML/KYC וכללים פנימיים. בדיוק בנקודות החיבור הללו מופיעות לרוב טעויות, שבגללן הפרויקט נתקע בשלב ההשקה.
אם העסק כבר לא רוצה לחיות בתוך מגבלות של מכסות של צדדים אחרים, תעריפים, כללי תהליך האונבורדינג וקצב שינוי המוצר, השירות מאפשר להעריך מעבר לרישיון עצמאי או למודל תאגידי וחוזי יציב יותר.
השירות בכיוון "הקמה משפטית של מערכת תשלומים באיחוד האירופי" מועיל במיוחד לצוותים שכבר מבינים את המוצר והמטרה המסחרית באיחוד האירופי, אך עדיין לא קיבעו את הארכיטקטורה המשפטית הסופית. בשלב זה ניתן, ללא עלות מיותרת, לתקן את מבנה החברה, את לוגיקת ההסכמים, את האתר, את תהליך ה-onboarding ואת סדר העבודה מול הרגולטור או מול שותפים מרכזיים.
בפתיחה, במסגרת השירות "השקה משפטית של מערכת תשלומים באיחוד האירופי", בדרך כלל מנתחים את ארכיטקטורת ה-payment, שרשרת הסליקה, ה-trade/Customer flows, הרקונסיליאציה והקמת הספק (provider setup). המטרה של בדיקה כזו היא להפריד בין פעילותה האמיתית של החברה לבין האופן שבו השירות מתואר באתר, במצגת ובציפיות הפנימיות של הצוות. דווקא כאן מתברר איזה חלק מהמודל אנו מגנים מבחינה משפטית, ומאיזה חלק נדרש לבצע שינויים עד להגשה או להפעלה.
ניתוח משפטי מאוחר עולה ביוקר, משום שהעסק כבר מספיק לקשור את המוצר, השיווק והסכמים מסחריים סביב הנחה שייתכן שהיא שגויה. עבור "השקת מערכת תשלומים משפטית באיחוד האירופי", טעות טיפוסית היא לא לקבוע היכן בדיוק במערכת מתבצעת פונקציה מפוקחת. לאחר השקה מבצעית, שגיאות כאלה משפיעות כבר לא על מסמך אחד, אלא על מסלול הלקוח, ה-support, על הגדרת ההסכמים עם ספקי שירותים ועל הבקרה הפנימית.
התוצאה המעשית של השירות "ההשקה המשפטית של מערכת תשלומים באיחוד האירופי" - אינה תיק מופשט עם טקסטים, אלא מבנה עבודה לשלב הבא: מפת דרכים ברורה, סדרי עדיפויות לפי מסמכים ונהלים, רשימת נקודות תורפה של המודל ועמדה חזקה יותר במשא ומתן עם הבנק, הרגולטור, המשקיע או שותף תשתיתי.
מסגרת משפטית. עבור שירותי תשלום ומסמכים אלקטרוניים של פרויקטים באיחוד האירופי, המסמכים המרכזיים הם בדרך כלל PSD2 - Directive (EU) 2015/2366 על שירותי תשלום בשוק הפנימי, ולמודלים עם הנפקת כסף אלקטרוני - Directive 2009/110/EC על כסף אלקטרוני. בהתאם למוצר, נלקחים בחשבון בנוסף מעשי הטמעה מקומיים, דרישות AML/KYC, GDPR, כללי מיקור חוץ, הגנה על כספי לקוחות, ממשל תאגידי וגילויים ללקוחות.
בפועל, משמעות הדבר היא ששירות משפטי בכיוון כזה חייב לבדוק לא רק את תוכן הבקשה, אלא גם את המוצר עצמו: מי מקבל את הכסף, היכן מתעוררות דרישות הלקוח, מי מנהל את הרישום, מי מבצע אונבורדינג, איך בנויים האינטגרציות, מה כתוב באתר ואיך מתואר השירות בחוזים עם שותפים. בדיוק בצומת של האלמנטים הללו מתעורבות מרבית הבעיות בעת קבלת רישוי ואונבורדינג בנקאי.
עבור השירות "השקה משפטית של מערכת תשלומים באיחוד האירופי" סיכון בסיסי הוא לבנות מודל על סיווג שגוי של הפעילות בפועל. אם הצוות לא הבין את ארכיטקטורת ה-payment, שרשרת ה-settlement, תהליכי המסחר/הלקוחות, ה-reconciliation והקמת הספק, הוא עלול בקלות לקבל את השם השיווקי של השירות כמציאות משפטית ולהתחיל לנוע במסלול שגוי ברחבי האיחוד האירופי.
גם מוצר חזק נראה חלש אם האתר, ההבטחות הציבוריות, תנאי השירות, הנהלים הפנימיים וההסכמים עם שותפים מתארים תפקידים שונים של החברה. במצב כזה, "השקה משפטית של מערכת תשלומים באיחוד האירופי" כמעט תמיד נתקלת בשאלות מיותרות במהלך בדיקת נאותות (due diligence), בבדיקת הבנק או בתהליך האימות באיחוד האירופי.
סיכון נפרד בשירות "הקמת מערכת תשלומים משפטית באיחוד האירופי" מתעורר בנקודות התלות בצדדים שלישיים ובבקרות פנימיות. אם לא מגדירים מראש מי אחראי על פונקציות קריטיות, כיצד מעודכנות הנהלים ואיפה מסתיימת אחריות הספק, הפרויקט נשאר פגיע דווקא באותם צמתים שמרכיבים את ארכיטקטורת התשלומים, שרשרת הסליקה, מסלולי הסחר/customer, ההשוואה (reconciliation) והגדרת הספק (provider setup).
השגיאה היקרה ביותר עבור "השקה משפטית של מערכת תשלומים באיחוד האירופי" היא לדחות את ההתאמה המשפטית עד לשלב מאוחר. כאשר מתברר שלא ניתן לקבוע היכן בדיוק במערכת מתבצעת הפונקציה הרגולטורית, החברות נאלצות לשכתב לא רק מסמכים, אלא גם את מסלול הלקוח, טקסטים של המוצר, סקריפטים של התמיכה, אונבורדינג ולפעמים אפילו את המבנה התאגידי באיחוד האירופי.
מה העסק מקבל בסיכום. עם סיום השירות בתחום "הקמה משפטית של מערכת תשלומים באיחוד האירופי", החברה מקבלת לא רק אוסף קבצים, אלא בסיס משפטי שאותו ניתן להשתמש עבור הצעדים הבאים: רישוי, רישום, משא ומתן עם בנקים ושותפי עיבוד תשלומים, הגדרה פנימית של תהליכים, בדיקת נאותות (due diligence), שינוי מבנה תאגידי או השקת מוצר חדש לשוק.
למה זה נותן השפעה מעשית. התוצאה של שירות כזה עוזרת לצוות לקבל החלטות מהר יותר: ברור היכן עובר הגבול בין מודל טכנולוגי מותר לבין activity המוסדר, אילו מסמכים צריכים להתפרסם באתר, אילו נהלים צריך להטמיע לפני ההפעלה, ואילו אפשר להפעיל בשלבים. עבודה זו חשובה לא רק בשלב ההתחלה. לאחר השלמתה, קל יותר לחברות לעדכן את המוצר, להתרחב למדינות חדשות, לתאם הסכמים חדשים עם ספקים ולעבור בדיקות נוספות מצד הבנקים, המשקיעים, המבקרים ויתר המשתתפים החיצוניים.
מה חשוב לאחר סיום השירות. האריזה המשפטית לא צריכה להישאר כארכיון. התפקיד שלה הוא להפוך לכלי עבודה עבור מייסדים, operations, compliance, product ו-business development. רק אז מצטמצם הסיכון שבחלוף כמה חודשים הפרויקט ייאלץ לאסוף מחדש את האתר, החוזים, הנהלים ונתיב הלקוח בהתאם לדרישות של בנק חדש, רגולטור, משקיע או שותף אסטרטגי.
מה הלקוח מקבל בסיכום. הערך המרכזי של שירות כזה הוא לא אוסף של קבצים מפוזרים, אלא בסיס משפטי מתואם כדי להפעיל ולצמוח. לאחר הכנה נכונה, לפרויקט קל יותר להסביר את המודל שלו לבנקים, לשותפי EMI/PI, לספקי שירותי עיבוד, לספקי KYC/AML, למשקיעים ולרוכשים פוטנציאליים של העסק. גם אם האסטרטגיה הסופית כוללת התחלה דרך מסגרת שותפים, אריזת משפטית איכותית מפחיתה מראש את הסיכון שבחלוף כמה חודשים יהיה צורך לשכתב מחדש את האתר, החוזים, נוהלי AML ואת סביבת העבודה הפנימית של תהליכי העובדים מאפס.
למה לא כדאי לדחות את העבודה הזו. ככל שהחברה עושה מאוחר יותר הגדרה משפטית תקינה של היקף המשימה עבור השירות "השקה משפטית של מערכת תשלומים באיחוד האירופי", כך התיקונים עולים יותר. אם קודם מפתחים מוצר, טקסטים שיווקיים, אונבורדינג ואינטגרציות, ורק לאחר מכן מגלים שמודל דורש היקף regulatory רגולטורי אחר או חלוקה אחרת של תפקידים, צריך לשכתב לא רק מסמכים, אלא גם ממשקים, נתיב תשלומים, תהליכי support, accounting logic ולעיתים אפילו corporate setup. לכן נכון יותר לבצע עבודה כזו לפני האצה פעילה, לפני כניסה למדינה חדשה ולפני משא ומתן רציני עם בנקים או משקיעים.
איך להשתמש בתוצאה בהמשך. חומרים שהוכנו במסגרת השירות בדרך כלל הופכים לבסיס לשלבים הבאים: התאגדות, בנק-אונבורדינג, בחירת ספקי טכנולוגיה, איסוף בקשה רגולטורית, אישור הסכמים עם שותפים, הכנת data room ועבודה פנימית של הצוות. עבור המייסד זה חשוב גם מסיבות ניהוליות: מתקבלת בהירות לגבי אילו פונקציות נדרשות פנימית, מה מותר להעביר החוצה לאאוטסורסינג, אילו מסמכים חייבים להיות מפורסמים באתר, אילו תהליכים יש לאוטומט כבר מיד, ואילו ניתן להתחיל בהדרגה.
סיכום מעשי לעסקים. שירות שהוכן היטב עוזר לקבל החלטות מהר יותר ובזול יותר: ברור האם כדאי ללכת על רישיון עצמי, האם אפשר להשיק דרך שותף, היכן עובר הגבול בין שירות טכנולוגי לבין activity מוסדר, אילו רכיבים במודל הם קריטיים לרגולטור ואילו שאלות ניתן לסגור באופן חוזי. בדיוק זה בדרך כלל קובע כמה מהר הפרויקט יגיע מהרעיון להשקה תפעולית ממשית בלי פניות מיותרות.
עדיף להתחבר לפני ההנפקה, לפני חתימת חוזי המפתח ולפני ההתרחבות הציבורית של המוצר. עבור השירות "הקמה משפטית של מערכת תשלומים באיחוד האירופי" זה חשוב במיוחד באיחוד האירופי, משום שהגדרה מוקדמת של היקף המשימה מאפשרת לשנות את המבנה ואת המסמכים בלי צורך בשכתוב מדורג של האתר, ה-onboarding, שרשרת החוזים והיחסים עם צדדים מתקשרים.
כן, בכיוון "השקה משפטית של מערכת תשלומים באיחוד האירופי" אפשר לחלק את העבודה: בנפרד מזכר, מפת דרכים, חבילת מסמכים, ליווי ההגשה או בדיקה של חוזה מסוים. אבל לפני כן כדאי לבצע בדיקה קצרה של payment architecture, settlement chain, trade/customer flows, reconciliation וה-provider setup, אחרת אפשר להזמין מקטע שלא יסיר את הסיכון העיקרי דווקא במודל הזה באיחוד האירופי.
ברוב המקרים הפרויקט מאט לא בגלל טופס אחד ולא בגלל רגולטור אחד, אלא בגלל פער בין המוצר, טקסטים של משתמשים, לוגיקה חוזית, נהלים פנימיים ותפקיד הממשי של החברה. עבור "השקה משפטית של מערכת תשלומים באיחוד האירופי" דווקא הפער הזה בדרך כלל יקר ביותר, כי הוא נוגע גם לשותפים, גם לצוות, וגם לקומפליינס הנוסף באיחוד האירופי.
תוצאה טובה עבור השירות "השקת מערכת תשלומים משפטית באיחוד האירופי" היא כאשר לעסק מופיע מודל מוגן וברור של הצעדים הבאים: אילו פונקציות מותר, אילו מסמכים ונהלים הם חובה, מה צריך לתקן לפני ההשקה ואיך לדבר על הפרויקט עם הבנק, הרגולטור, המשקיע או שותף טכנולוגי בלי עמימות פנימית באיחוד האירופי.
