שקל דיגיטלי

פורום תעשייה פיננסית – סיכום פגישה מס' 7 מיום 18/12/24

הפגישה התקיימה באמצעות יישומון Teams, רשימת משתתפי הפורום מופיעה בנספח.

 

חלק ראשון: סיכום ההתייחסויות שהועברו על ידי חברי הפורום בעקבות המפגש הקודם לנושא "מגבלות החזקה בשקל הדיגיטלי", ניר יעקבי ואמיר משה (מצגת מצורפת).

אסטרטגיית קביעת המגבלות: חברי הפורום נשאלו בנוגע לאסטרטגיית מגבלות ההחזקה – האם יש להחיל את המגבלות מיד עם ההנפקה, ואם כן, לאיזה טווח זמן מגבלות אלו יחולו, והאם ניתן להסירן לאחר שניתן זמן למערכת הבנקאית להתאים את תמהיל המקורות שלה. תגובות משתתפי הפורום היו שהסרת מגבלות תביא למחסור במקורות אשראי ולכן יש צורך במגבלות החזקה באופן מתמיד. בנוסף, מנגנונים של "המפל" ו"המפל ההפוך" יאפשרו מגבלת החזקה מבלי לפגוע בחוויית המשתמש. הערה נוספת הייתה שמתן ריבית על השק"ד סותר את המטרה בהצבת מגבלות החזקה, שכן הריבית מתמרצת העברת  פקדונות לשק"ד. תגובה נוספת הייתה שיש להנפיק עם מגבלות, אך ניתן לעדכן אותן מדי פעם לפי סוג לקוח.

 

אפיון סגמנטים: משתתפי הפורום נשאלו כיצד יש להתאים את גובה המגבלה לסוגי המשתמשים השונים. תגובת המשתתפים בפורום היו שיש להבדיל בין סוגי המשתמשים השונים,  אפילו עד לרמת המשתמש הבודד.  

 

סיכון מיידי לעומת סיכון מתמשך: בעיית הנזילות בבנקים והסיכון המתמשך של התייקרות מקורות האשראי וירידה ברווחיות הבנקים. האם יש להתחשב בקביעת המגבלות לטווח הקצר גם בסיכונים של הטווח הארוך, והאם ניתן לפתור את בעיות הטווח הארוך על ידי טיפול בבעיות הטווח הקצר. תגובת המשתתפים הייתה שיש לפעול באופן שמרני מכיוון שיהיה קשה לצפות את השימוש העתידי בשק"ד והיקפו. תגובה נוספת הייתה שיש לבחון לא רק את ה-LCR אלה גם את ה-,NSFR כדי לבחון את פרופיל המימון של הבנקים בטווח הארוך.

 

נתוני הבנק הבודד: האם ובאיזה רמה יש להסתכל גם על הבנק הבודד ולא רק על המערכת הבנקאית הכוללת. תגובת המשתתפים היו חלוקות: מצד אחד, נטען שאין חשיבות להסתכלות מערכתית אלה יש לבחון את הבנק הבודד. מנגד, נטען שניתן להתבסס על נתוני המערכת ולא הבנק הבודד, כי הבנקים הקטנים שומרים על יחסי נזילות גבוהים יותר מהבנקים הגדולים, כך שניתן יהיה להסתמך על הממוצע שמשקף בעיקר את הבנקים הגדולים ולא חייבים לבחון כל בנק בודד.

מודל הנזילות: האם המודל שהוצג הוא בסיס טוב להגדרת מגבלת החזקה. תגובת המשתתפים היו שכן, יש לבדוק את ההשפעה על רווחיות הבנקים ולא רק על נזילותם. הצוות ציין שהנושא נבדק ונראה שההשפעות על הרווחיות לא צפויות להיות מאוד משמעותיות. בנוסף, נאמר שיש לחשב גם את החזקות הבנקים ב-CBDC כחלק מהנזילות של הבנק. הצוות הסביר שמבחינת ניהול הנזילות אחזקות שק"ד על ידי בנק שקולות לאחזקות מזומן או עו"ש בבנק ישראל.

 

תגובת המשתתפים:

  • ניכר שיש מאמץ רב בפיתוח אמצעי תשלום חדש ויש לשכנע את משתמש הקצה שכדאי לו להשתמש בו. אם השק"ד לא יהיה אטרקטיבי, לא יהיה אימוץ שלו. יש לחשוב על ההשפעה של הטלת מגבלות. תגובת הצוות: יש צורך באיזון בין היציבות של המערכת הבנקאית וחווית המשתמש, וכפי שצוין יהיו מנגנונים כמו המפל/מפל הפוך שיעזרו לאיזון הזה.

 

חלק שני: "תשלומים מותנים ומתקדמים בשקל הדיגיטלי, צחי בן יוסף ואמיר משה (מצגת מצורפת).

מסע שימוש "בסיסי" לעומת "מתקדם":

בטרם נצלול לפונקציונליות מתקדמת ויכולות מתקדמות בליבת המערכת, נעסוק תחילה בפישוט הנושא על ידי הגדרות 2 קצוות אפשריים לאופי המערכת: לכאורה היא יכולה לאפשר רק פעולות המשקפות מסע שימוש בסיסי: הצטרפות, טעינת הארנק וביצוע תשלומים בסיסיים. במקרה כזה האחריות לפיתוח פעולות מתקדמות יותר במערכת השק"ד תוטל במלואה על המשתתפים, ותלות המשתמשים במשתתפים תהיה גדולה יותר.

מנגד, יתכן כי המערכת תאפשר בליבת הביצועים שלה פעולות המאפיינות מסע שימוש 'מתקדם' – המאפשר גם היבטים מורכבים יותר כגון תשלומים מותנים, תשלומים מפוצלים, שליטה בסטאטוס ארנקים ועוד. מערכת כזו תתפקד כ 'Level Playing Field', תאפשר לכלל המשתתפים גישה לפונקציות זהות ולרשת הרחבה של המשתמשים, מה שימנע walled gardens'' וצפוי להגביר את התחרות והחדשנות בשק"ד. זוהי גישתנו למערכת ובהמשך נדון בפונקציונליות המתקדמת הצפויה לה.

נבהיר, כי כאשר מדברים על תשלומים מותנים, אין הכוונה לכסף מתוכנת ("Programmable money"),  - כסף המכיל מאפיינים או תנאים ספציפיים (תוקף, שימוש למטרות מסוימות וכו'). השק"ד הוא כסף שניתן לעשות בו כל שימוש בכל עת כמו כל סוג אחר של כסף, ותמיד יישאר ביחס 1:1 עם מזומן.

 

העבודה התמקדה ב-2 שאלות עיקריות:

  1. מהן היכולות והפונקציונאליות הנדרשות במערכת הליבה, בכדי לאפשר תרחישי שימוש שונים בתשלומים מותנים, על בסיס מערכת המהווה Level Playing field:
    1. פונקציונליות שהמערכת חייבת לספק כדי לתמוך בתרחישי שימוש שונים (למשל נעילת כספים)
    2. פונקציונליות שכדאי שהמערכת כדי למקסם יעילות ולתמוך בסטנדרט טכנולוגי אחיד בין המשתתפים (למשל תמיכה  בהקפאת ארנק או השבתה זמנית שלו)
  2. למי תינתן היכולת  להגדיר, לשנות ולעדכן את הפונקציונליות שתוטמע בליבת המערכת?

 

תשלומים מותנים יבוצעו על פי לוגיקות עסקיות המחולקים ל-3 סוגים עיקריים:

  1. לפי הזמן בו יבוצע התשלום;
  2. לפי מאפיינים הקשורים בשימוש;
  3. לפי התניה חיצונית (למערכת).

לאחר מילוי תנאי הקדם לביצוע העסקה, יבוצע התשלום. כמובן שיכולים להיות שילובים בין לוגיקות שונות בתשלום אחד. כדי שמערכת שק"ד השואפת ל-Level playing field תוכל לתמוך בלוגיקות אלו, נדרשות יכולות מסוימות בליבת המערכת: כך למשל, כדי שמערכת תוכל לתמוך באופן רוחבי בתשלומים מותני זמן, נדרש למערכת שעון למתן זמן אחיד למשתתפים וכן לחותמת זמן לפעולות תשלום שהתרחשו על גביה. במקרה של התניות חיצוניות למשל, שדורשות הבטחת תשלום בעת התקיימות התנאי, ידרשו יכולות הקשורות לנעילה ושחרור הנעילה של הכספים כמו גם קבלת מידע לגבי הנעילות. כמובן שעל בסיס הפונקציונליות הזו, יהיו גם פונקציות משלימות ומתקדמות יותר, שעשויות אבל הן לא חייבות להיות בליבת המערכת, אלא יכולות להיות מוצעות על ידי  המשתתפים.

 

למי תהיה גישה לליבת המערכת להגדרת פונקציונליות מתקדמת?

גישה לליבת המערכת יכולה להיות ריכוזית (Centralised), כלומר רק הבנק המרכזי יוכל לגשת ולהגדיר פונקציות במערכת הליבה, חצי ריכוזית Semi-Centralised)), בה גם משתתפים יוכלו להגדיר ולערוך פונקציות, או מבוזרת לגמרי (Decentralised), בה כלל המשתמשים יוכלו לגשת לליבת המערכת, בדומה לפלטפורמות בלוקצי'יין ציבוריות.

ככל שהמערכת יותר ריכוזית, כך הנטייה לחדשנות תפגע, ולהיפך. מצד שני, מתן אפשרות למספר רב של גופים לשנות את הפונקציונליות יוצר סיכונים משמעותיים. לאור העובדה שמדובר במערכת לאומית עם תיאבון סיכון נמוך, , ניתן כבר בשלב הראשון של הדיון להוריד מהפרק גישה של משתמשים להגדרת פונקציונליות, ועיקר הדיון עוסק בהאם יש לאפשר למשתתפים גישה, כדי למטב חדשנות. לאור הסיכונים ומכלול השיקולים שהצגנו במצגת, המלצתנו היא להתמקד בגישה לפיה הגדרת הפונקציונליות בליבת המערכת תבוצע אך ורק תוך מעורבות ישירה של הבנק המרכזי (centralized), תוך הבניית האפשרות למשתתפי המערכת להציע פונקציונליות חדשנית ומתקדמת שתוטמע בליבת המערכת. שאלת המימוש הטכנולוגי עומדת בעינה – המימוש יכול להיות בטכנולוגיה מבוזרת או בטכנולוגיה ריכוזית (שקף 15 במצגת).

יכולות מתקדמות

יכולות מתקדמות יכולות לכלול, לדוגמא, ארנק משנה, תשלום מפוצל, מנגנון מפל ומפל הפוך וכד'. השאלה היא אילו מהיכולות המתקדמות צריכות להיתמך על ידי ליבת מערכת השק"ד. במצגת הוצגה טבלה עם מיפוי של יכולות מתקדמות (שקף 17), פונקציונאליות רלוונטית להן, וניתוח האם נדרשת מעורבת של ליבת מערכת השק"ד לניהול היכולות הללו. המלצתנו היא להבטיח שהפונקציונאליות ברמת הבנק המרכזי תתמוך לכל הפחות באפשרות משתתפי המערכת לבצע את הפעולות הבאות:

  • ניהול סטאטוס ארנקים: היכולת להקפיא ארנק לפעולות תשלום (עדיין יוכל להמשיך לקבל כסף) וכן השבתה זמנית של ארנק. במקרה זה אנו סבורים כי ככל שהההחלטה לאפשר למספר PSPs לגשת לארנק בודד, ניהול סטאטוס הארנק צריך להתנהל ברמה מרכזית במערכת.
  • תשלום מתפצל (SPLIT): עסקת תשלום אחת למספר מוטבים בעסקה אחת. במקרה זה אנו חושבים שלכל הפחות, הבנק המרכזי יתמוך באפשרות ה-PSP לברר האם ארנקי המוטבים בפעולת התשלום קיימים ונמצא במצב תקין לקבלת התשלום.

בסיום המצגת (שקף 19), הובאו המלצות לפונקציונליות המתקדמת הנדרשת ברמת ליבת המערכת השק"ד.

 

הוצגו שתי שאלות למשתתפי הפורום:

  • האם אתם מזהים צרכים חיוניים בפעילות שלכם שחשוב שתהיה בליבת המערכת ולא הוזכרו?
  • בנוגע להמלצה לפיה הגדרת הפונקציונליות בליבת המערכת תבוצע אך ורק תוך מעורבות ישירה של הבנק המרכזי (Centralised), נבקש לקבל את חוות דעתכם על ההשלכות על היבטים כגון: תחרותיות, פרטיות חדשנות, והיבטים נוספים.

 

התייחסות מהמשתתפים:

  • האם יש תרחישי שימוש יותר מתקדמים בשקל הדיגיטלי שעבורם נצטרך לדעת מידע שונה ויותר מעמיק לגבי המשתמשים שיכול לחדור יותר לפרטיות שלא מצטרך עבור פעולות בסיסיות?

תגובת הצוות: לדעתנו המסר לא חייב לעבור במערכת השק"ד, דרך המערכת תעבור רק הוראה של ביצוע תשלום. המערכת לא תשמור מידע על עסקאות, המידע ישמר אצל ה-PSPs ככל והמשתמש ירצה.

  • עד כמה יש מודל למעורבות של בנק ישראל באישורים של ה-PSPs ושל הפיתוחים שלהם? כלומר מה יהיה המודל הרגולטורי לקבלת אישור לפעילות במערכת השק"ד?

תגובת הצוות: לגבי נושא הרישוי של PSPs, יהיה דרוש רישוי תוך התחשבות בכללי AML, הגנה צרכנית ואבטחת מידע, אך לא יצטרך לקבל אישור כמחזיק נכס פיננסי כי הוא לא מחזיק בעצמו בכסף של משתמש הקצה, בשונה מספקי שירות תשלום הקיימים כיום.

  • האם נעשתה חשיבה על המודל של האחריות של הבנק המרכזי ואיך המודל הזה ישפיע על האחריות?

תגובת הצוות: לבנק המרכזי תהיה אחריות על תקינות המערכת. האחריות על פיקוח על AML מורחקת מהבנק המרכזי, זו המומחיות של ה-PSPs  שמכירים את הלקוחות שלהם. גם חובות ההגנה צרכנית מוטלות על ה-PSPs.

 

  • לגבי פונקציה של הוראת קבע, האם מערכת השק"ד תדע להתחשב בזה ולשמור את הכסף לביצוע פעולה כזאת?

תגובת הצוות: הוראת קבע זו דוגמה לתשלום מותנה שקיים גם היום, ושניתן להתחייב אליה ללא הצורך להבטיח שהכסף לתשלום ההתחייבות נמצא כל הזמן בחשבון. בגלל שהשק"ד הוא מיידי וסופי אם הוראת הקבע תפעל ולא תהיה כסף בארנק ההוראה תדחה. זו תהיה פונקציה של PSP לדאוג שהעברות כאלה יעברו ולדאוג שכסף ישמר בארנק להוראה, במידה וההתנייה נדרשת, על בסיס פונקציונליות מתקדמת שמערכת השק"ד תאפשר.

 

 

חלק שלישי: "פעילות לא מקוונת בשקל הדיגיטלי", אסף דוד-מרגלית וד"ר ניר יעקבי (מצגת מצורפת).

מוטיבציות לפעילות לא מקוונת

  • זמינות תשלומים: לאפשר לציבור המשתמשים לבצע פעולות תשלום בשקל דיגיטלי גם באזורים ללא כיסוי סלולרי או בזמנים של בעיות תקשורת או תקלות טכניות.
  • יתירות: לאפשר לציבור המשתמשים לבצע תשלומים דיגיטליים גם במקרה של כשל במערכת המקוונת.
  • שיפור ביצועי מערכת: הפחתת עומס על רכיבי המערכת ואפשרות לבצע תחזוקת חירום ללא השבתה מוחלטת של שירותי התשלום.
  • אנונימיות: יצירת חווית שימוש דמוית מזומן, לחיזוק האמון בשק"ד והגברת תחושת הפרטיות.

 

סיכונים בפעילות לא מקוונת

כאשר משתמשים מעבירים כסף בשקל הדיגיטלי באופן לא מקוון, צפים מספר סיכונים. חלק מהסיכונים מתגברים כאשר מדובר בעסקאות אנונימיות:

  • אי יכולת לנטר עסקאות חשודות בזמן אמת
  • הפסד כספי: במקרה של אובדן או גניבת המכשיר שמחזיק את השק"ד, מה שעלול להחמיר עקב התקפות פיזיות של גניבת המכשיר, וכן ניסיונות פריצה והעתקה פיזיים ל/של ארנק.
  • תשלום כפול: סכום כסף עלול לעבור ליותר ממשתמש אחד ללא מחיקתו מארנק המשלם, מה שעלול לעודד לזיופים והונאות.
  • עדכוני מערכת: עדכון גרסה או עדכון מערכת לא יגיע לארנקים הלא מקוונים.

 

אפיון השק"ד הלא מקוון

האפיון מתוכנן כך שהפונקציונליות תענה על המוטיבציות בפיתוח שק"ד לא מקוון תוך כדי ניהול הסיכונים שבפיתוח, במינימום פגיעה בחווית הלקוח.

 

טעינה והחזקה: פעילות תשלום לא מקוון בשק"ד תהיה אפשרית, וכל PSP יחויב להנגיש ללקוחותיו שירות וארנק שק"ד לא מקוון. טעינת שק"ד לא מקוון תתבצע מארנק מקוון של אותו משתמש כאשר הוא במצב מקוון. בנוסף, תהיה אפשרות לטעון ארנקי שק"ד לא מקוונים בכספומטים או דלפקי FI שיאפשרו משיכה והפקדה כנגד מזומן. תהיה אפשרות לפתוח מספר ארנקים לא מקוונים באמצעות ה-PSP, כאשר כל אחד מהארנקים הללו יוכל להיות מותקן על אמצעי קצה אחד בלבד, המכיל רכיב מאובטח, אשר בו ישמרו יתרות השקל הדיגיטלי הלא מקוון. בעסקאות שאינן אנונימיות, פרטי העסקה שבוצעו יישמרו על הרכיב המאובטח, בדומה לעסקאות מקוונות.

 

התממשקות: ארנק לא מקוון יידרש, בהתאם לקריטריונים המינימאליים שיקבעו, להתממשק עם מערכות ה-PSP  כדי לסנכרן נתונים על פעולות לא מקוונות שבוצעו. אם לא התממשק בפרק זמן/סכום יוצא שיוגדר, הארנק יוקפא ולא ניתן יהיה להשתמש בו לפעולות תשלום יוצאות, עד להתממשקות. במהלך ההתממשקות יבוצע סנכרון שבו ה-PSP יעודכן בפעילות הארנק, והארנק יעודכן בעדכוני המערכת ככל שהיו כאלה. בנוסף, במקרה שבו הארנק חייב בעמלות לבית עסק, הסכום יינעל ברכיב המאובטח, עד להתממשקות, ואז  תועבר העמלה לזכאים.

 

הגנה צרכנית ומגבלות: ה-PSP  יידרש ליידע את המשתמש שאובדן הארנק הלא מקוון משמעו אובדן פוטנציאלי של הערך הצבור בו. מערכת השק"ד תוכל ליישם מגבלות על פעילות לא מקוונת, וארנק לא יוכל לקבל כספים מעבר למגבלה שתוגדר. מגבלת ההחזקה של ארנק השקל הדיגיטלי הלא מקוון תהיה חלק מהמגבלה הכללית על המשתמש, שתוגדר על ידי המערכת. בנוסף, PSPs  יוכלו לקבוע מגבלות מחמירות יותר על לקוחותיהם, משיקולי ניהול סיכונים (אך יהיה עליהם לאפשר מינימום שיקבע ע"י המערכת).

 

ארנקי "תקשורת פאסיבית": תתאפשר החזקה של ארנקים בעלי "תקשורת פאסיבית" שאין להם יכולות תקשורת ומקור אנרגיה עצמאים ולכן יידרשו להסתייע באמצעי גישה בעלי תקשורת אקטיבית לצרכי ההתממשקות.

 

שאלות למשתתפי הפורום:

  1. האם יש בעיות/אתגרים/סיכונים שהייתם מעוניינים שניתן להם התייחסות מיוחדת, בקשר לדרך בה חשבנו על שק"ד לא מקוון או בכלל?
  2. דעתכם על תשלומים אנונימיים לא מקוונים?

הערות/הצעות/רעיונות נוספים?

תגובות המשתתפים:

  • לגבי משתתפים אנונימיים ולא אנונימיים, יש לאפשר ל-PSP להגביל כל משתמש, בין אם הוא אנונימי ובין אם לא, מכיוון שהם מכירים את לקוחותיהם ויודעים אילו הגבלות יש להחיל עליהם.

תגובת הצוות: כאשר אנו מדברים על אנונימיות, הכוונה היא לתשלום אנונימי ולא למשתמש אנונימי. כלומר, האפשרות להעביר תשלום מבלי שניתן יהיה לראות למי הועבר הכסף ומי העביר אותו.

  • בפועל תשלומים אנונימיים משתמשים למטרות שהמדינה תמיד מנסה למנוע, כגון הלבנת הון או מימון טרור. תשלום אנונימי חותר נגד מאמצים אלו.

תגובת הצוות: יש פה איזון עדין. במזומן, התשלומים הם אנונימיים לחלוטין, אך קיימות רגולציות על סכומים שניתן לבצע בהם תשלום או משיכות במזומן. לעומת זאת,  אמצעי תשלום דיגיטליים אינם אנונימיים כלל, וספקי שירותי התשלום יודעים בדיוק אילו תשלומים בוצעו ועבור מה. השקל הדיגיטלי נמצא על הספקטרום הזה, אם כי רחוק יותר מהמזומן. עם זאת ניתן לגדר את תחום לבנת ההון לרמות סבירות באמצעות מגבלות על תשלומים אנונימיים.

נספח - רשימת משתתפים – מפגש שביעי