בנקאות מרכזית, ענן, מיקור חוץ ופיקוח טכנולוגי.

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

מה שעושה מערכת בנקאות ליבתית

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

פונקציות טיפוסיות כוללות:

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

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

בחירות ארכיטקטורה

בנקים חדשים לרוב בוחרים בין שלושה מודלים.

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

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

חוקי מיקור חוץ

מיקור חוץ פירושו שספק שירות מבצע תהליך, שירות או פעילות שהבנק היה מבצע אחרת בעצמו. באיחוד האירופי, EBA הנחיות על הסדרים של מיקור חוץ (EBA/GL/2019/02) נכנסו לתוקף ב-30 בספטמבר 2019. הם החליפו הוראות קודמות, כולל ההמלצה הנפרדת של EBA על מיקור חוץ לספקי שירותי ענן.

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

פונקציות קריטיות או חשובות

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

1. לבצע הערכת סיכונים ופיקוח על הספק לפני חתימת החוזה.
2. כולל זכויות חוזיות של גישה, מידע וביקורת עבור הבנק והרשות האחראית.
3. שליטה על מיקור חוץ, כולל הודעה והזכות להתנגד או להפסיק.
4. להציג את דרישות אבטחת המידע, המיקום והסודיות.
5. תיעדו ובדקו אסטרטגיות יציאה.
6. לדווח לרשויות האחראיות מראש על עבודת מיקור חוץ קריטית או חשובה.

כל ההסדרים חייבים להיות רשומים ברשימת מיקור חוץ שמנוהלת על ידי הבנק.

חוץ מהאיחוד האירופי

בממלכה המאוחדת, PRA הצהרת המפקח SS2/21 על מיקור חוץ וניהול סיכון של צד שלישי, שפורסמה במרץ 2021 ונכנסה לתוקף ב-31 במרץ 2022, מכסה חומריות, אבטחת מידע, תכנון ענן ויציאה. PRA מתאר אותה כמטרתה להקל על "עמידות גדולה יותר ואימוץ הענן וטכנולוגיות חדשות אחרות".

בסינגפור, MAS ניהול סיכונים טכנולוגיה, שפורסם ב-18 בינואר 2021, קובע עקרונות לממשלת סיכון טכנולוגי, IT ועמידות סייבר, ומוספים על ידי הודעת מחייבת והנחיות לדיווח על תקרית.

DORA: עמידות פעולה דיגיטלית באיחוד האירופי

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. היא מביאה ניהול סיכון ICT, דיווחים על תקריות, בדיקות וסיכון של צד שלישי לתקנה אחת עבור רוב הגופים הפיננסיים של האיחוד האירופי, כולל בנקים.

אזור DORA	דרישת היסוד לבנקים
ניהול סיכון ICT	מסגרת מתועדת מאושרת ומנוהלת על ידי הגוף המנהל, הכולל זיהוי, הגנה, גילוי, תגובה והחזר.
דיווח אירוע	אירועים גדולים הקשורים ל-ICT חייבים להיות מדווחים לרשויות הרלוונטיות על פי סעיף 19, באמצעות סיווג ותבניות מותאמים.
בדיקת עמידות	תוכנית בדיקה עבור כל הישות; עבור הישות שהוגדרה על ידי הרשויות, בדיקות חדירתיות מודרניות המונעות על ידי איום לפחות אחת לשלוש שנים על מערכות ייצור חי תחת סעיף 26
סיכון של צד שלישי	אסטרטגיה לסיכון של צד שלישי ב-ICT, מינימום חוזים, ורשומה של מידע על כל חוזי השירות של ICT לפי סעיף 28
פיקוח על ספקים קריטיים	רשויות הפיקוח האירופאיות מגדירות ספקיות שירותים קריטיות של צד שלישי ומפקחות עליהן ישירות על פי סעיף 31.

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

DORA מתייחס לצד הנחיות EBA של מיקור חוץ. במציאות, הבנקים שומרים על מלאי אחד שמספק את שניהם.

אבטחת סייבר

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

בקרה מפתח כוללת בדרך כלל:

1. זהות חזקה וניהול גישה, עם אימות רב-גורמי ובקרה על גישה מוגבלת.
2. פיתוח תוכנה אבטחה וניהול שינויים, כולל לשחרורים של יצרנים.
3. הצפנה של נתונים בתנועה ובמנוחה, וניהול מפתחות שהבנק שולט.
4. מעקב רציף ויכולת לביצוע פעולות אבטחה, בתוך החברה או מחוצה לה.
5. ניהול פגיעות ובדיקת חריגה קבועה.
6. גיבוי המבודד מסביבת הייצור ונבדק לשחזור.
7. תוכניות תגובה לתקריות שמכסות הודעה רגולטורית ותקשורת עם הלקוח.

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

דיווח רגולטורי

בנקים מדווחים כמויות גדולות של נתונים למפקחים ולבנקים המרכזיים. סעיף 430 של CRR דורש ממוסדות לדווח על דרישות הון עצמי כולל יחס הנפקה, חשיפות גדולות, דרישות נזילות, עומס נכסים וחשיפה ESG, בין היתר, ומוסדות מסוימים חייבים גם לדווח מידע פיננסי.

דיווחים טובים רק ככל שהנתונים מאחוריהם, השרשרת ממערכת הליבה למערכת הפיקוח בדרך כלל הולכת כך:

1. מידע מקורי במערכת הליבה ובמערכות פעולה אחרות.
2. מחסן נתונים או שכבת דיווחים עם התאמה לדו"ח הכללי.
3. מנוע דיווחים רגולטורי שממפה נתונים לתבניות פיקוח וחוקי אישור.
4. ביקורת וחתימה על ידי הכספים והסיכון, עם בקרות מתועדות.
5. הרשמה דרך פורטל הרגולטור או פורמט.

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

מה המפקחים מחפשים בבקשה לרישיון

1. ארכיטקטורת יעד ברורה, עם כל מערכת, בעליה, הספק שלה והמיקומה.
2. מפה של פונקציות קריטיות או חשובות, המראה אילו פונקציות מועברות למי.
3. תוכניות יציאה עבור כל ספק קריטי, מציאותיות בזמן ובעלות.
4. מיקום הנתונים וגישה אליהם, כולל לרשויות המפקחות והפתרון.
5. בדיקת עמידות, עם זמן שיקום שמתאים להבטחות השירות של תוכנית העסקים.
6. הוכחות למוכנות, כגון בדיקות סוף-סוף, חזרות על הגירה וקבלה מבצעית.

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

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