הביקורת בעידן הבנקאות הפתוחה
התפתחות התפיסה והיישום של בנקאות פתוחה מבוססת API בישראל, מציבה אתגרים בפני הביקורת הפנימית בתאגידים פיננסיים. בין היתר, בבחינת תהליכי ההתאמה של האסטרטגיה ויצירת המסגרת ליישומה בתהליכי ניהול הסיכונים, ביישום טכנולוגיות חדשות ובהגנת הפרטיות והסייבר
הקדמה
בשנים האחרונות מתפתחת תפיסה של בנקאות פתוחה, שבבסיסה עומד העיקרון של פתיחת ממשק בין נותן השירותים הפיננסיים לבין צדדי ג', שבאמצעותו ניתן, בהסכמת הלקוח, לשתף מידע על הלקוח או ליזום תשלומים בחשבונו של הלקוח. לדוגמה, בדרך זו יכולים צדדים שלישיים (בהסכמת הלקוח) להציע לו לשירותי אגרגציה של מידע מכלל חשבונותיו, שירותי תשלום, ומוצרים פיננסיים המותאמים לצרכיו.
תפיסה זו מוּנעת על ידי כוחות רגולטוריים השואפים לקדם תחרות, על ידי התפתחויות טכנולוגיות המאפשרות לשחקנים חדשים להיכנס לזירת התחרות של השירותים הפיננסיים, ועל ידי השינוי שחל בטעמי הלקוחות, שהיום מורגלים לצרוך שירותים דיגיטליים בתחומים שונים ובסטנדרטים גבוהים של שירות וחוויית לקוח.
בתחום הרגולציה הגלובלית נזכיר את 2PSD – הדירקטיבה האירופית בנושא שירותי תשלום, את קבוצת ברלין, שהיא יוזמת תקינה אירופאית ומסגרת API המסייעת לבנקים לציית לרגולציית ה-PSD2, ואת הדוח של ה-BIS (The Basel Committee on Banking Supervision)בנושא בנקאות פתוחה ו-API מנובמבר 2019.
API – Application Programming Interface הוא סט של פונקציות המסופקות על ידי מקור המידע ומאפשרות לארגונים חיצוניים להתחבר ולהשתמש בנתונים או בשירותים המוחזקים על ידו.
במקביל נוצרים בעולם מודלים עסקיים חדשים הבאים לידי ביטוי בשיתופי פעולה בין בנקים מסורתיים או דיגיטליים לבין חברות פינטק וכניסה של הביג-טק לזירת השירותים הפיננסיים. התרחבות המגמה של בנקאות פתוחה מהווה עבור המערכת הבנקאית איום והזדמנות כאחד, המחייבים אותה לצעוד קדימה ולהיערך לשינוי המערכות הפיננסיות.
בהתאמה להתפתחויות אלה ובמסגרת גישה של תמיכה בחדשנות ועידוד התחרות, גיבש בנק ישראל הוראה שפורסמה בפברואר 2020 בנושא יישום תקן לבנקאות פתוחה בישראל, המבוסס על API (להלן "ההוראה"). בהוראה מוגדרים החובות והכלים לניהול הסיכונים הן עבור מקורות המידע ומנהלי חשבון התשלום והן עבור ספקי צד ג'. ההוראה חלה על בנקים וחברות כרטיסי האשראי ונקבע בה כי התשתית של בנקאות פתוחה בישראל תיפתח לצדדים שלישיים כשתושלם חקיקה בנושא בנקאות פתוחה ותוחל עליהם רגולציה בעניין זה.
גם הביקורת הפנימית נדרשת להתפתח ולהתאים את עצמה בהיבטים שונים על מנת להישאר רלוונטית ואפקטיבית, לרבות: היכרות עם עולמות התוכן העסקיים, הטכנולוגיות החדשות, ורכישת מיומנויות, כלים ושיטות חדשים.
בהמשך המאמר נסקור את הסוגיות והאתגרים העיקריים הכרוכים ביישום בנקאות פתוחה המבוססת על API, ובפרט את האתגרים העומדים לנוכח זאת בפני הביקורת הפנימית:
- התאמת האסטרטגיה העסקית והטכנולוגית
בנקים מתמודדים עם אימוץ האסטרטגיות הנחוצות על מנת להישאר תחרותיים ורווחיים בסביבה הדיגיטלית הדינמית והמשתנה. סביבה זו דורשת אימוץ מהיר של טכנולוגיות, התמודדות עם שחקנים חדשים בזירה, ודרישות רגולציה.
הביקורת צריכה לבחון את תהליכי התאמת האסטרטגיה ואת יצירת המסגרות ליישומה – מדיניות, תוכניות עבודה, הקצאת משאבים ליישום וניהול הסיכונים וכדומה.
- הגנת הפרטיות וניהול הסכמת הלקוח
הגישה שאומצה על ידי ה- GDPR((EU’s General Data Protection Regulation ובאה לידי ביטוי גם בהוראה היא שהבעלות והשליטה על המידע הן של הלקוח. לפיכך נקבעו כללים לקבלת הסכמת הלקוח, לשיתוף המידע ולניהול ההסכמות, לרבות זכות ביטול ההסכמה והחובה לחדשה מדי שנה.
על הביקורת לבחון את אפקטיביות התהליכים והאמצעים הטכנולוגיים הננקטים לצורך עמידה בהוראות הגנת הפרטיות וכפי הנגזר מהוראות בנק ישראל. יש לציין כי מערכת נתוני אשראי שעלתה לאוויר באפריל 2019 מציבה אתגרים דומים בפני הבנק הן כספק נתונים למאגר והן כמשתמש בו, ובהתאמה בפני הביקורת.
- הסדרים עם צדדים שלישיים, סיכוני מוניטין וגבולות האחריות
ההסדרים עם צדדים שלישיים תלויים ברגולציה ובמסגרת היחסים החוזית בינם לבין הבנקים.
לכן התפתחות שיתוף הנתונים עם צדדים שלישיים תלויה בהתפתחות התיאום הרגולטורי בין רשויות הפיקוח השונות (למשל: רשות שוק ההון, רשות ני"ע, הרשות להגנת הצרכן), וצמצום פערים ברגולציה.
בעולם של בנקאות פתוחה, שבו צדדים נוספים מעורבים, הקצאת אחריות במקרה של נזק כספי או של שיתוף שגוי או דלף מידע היא מורכבת יותר. סוגיה זו מעלה גם את סיכון המוניטין עבור הבנק, שכן במקרים של תלונות וסכסוכים לקוחות נוטים לפנות לישות מוסדרת, כלומר הבנק שלהם, גם אם צד שלישי אחראי לעסקה השגויה או לדלף המידע.
הביקורת צריכה בהתאמה לבחון את ההסדרים של הבנק עם צדדים שלישיים, התאמתם לדרישות הרגולציה, ותהליכי ניהול הסיכונים והבקרות המשולבים ביישומם.
- פיתוח ותחזוקה של ממשקי API
יישום בנקאות פתוחה כרוך בהתמודדות עם אתגרים של יצירה והפעלה של ממשקי Api, במונחי עלות, זמן, תעדוף ורמות שירות (בעיקר כאשר הם נעשים על בסיס דו-כיווני עם ארגונים מרובים). הוראת בנק ישראל קובעת רף מינימלי של רמת השירות הנדרשת, בין היתר בהיבטי זמינות, זמני תגובה, עדכניות הנתונים, אחידות ונתיבי ניטור ובקרה.
יצירה והפעלה של ממשקי Api כרוכות בדרך כלל באימוץ של מתודולוגיות Agile ו-DevOps, שנועדו להאיץ את אספקת התוצרים תוך הפחתת התקורה. בנוסף, הן כרוכות בהתמודדות עם יצירת ממשקים של מערכות התשתית המיושנות הקיימות ככלל בתאגידים הבנקאיים מול שירותים/יישומים חדשים.
הביקורת צריכה להיות בעלת הבנה במתודולוגיות החדשות לפיתוח, בדיקה וניהול גרסאות. עליה לוודא כי בקרות מיושמות כחלק מתהליכי עבודה אלה. כמו כן, עליה לקצר את טווחי הזמנים ולבצע ביקורות ממוקדות ומהירות תוך כדי תהליך.
- אתגרי הבטחת הנתונים והגנת הסייבר
השיתוף של נתוני לקוחות והקישוריות הגוברת בין הבנקים לישויות שונות, מגבירים את החשיפה לגניבת נתונים או שיבוש בנתונים. שיתוף הנתונים מגדיל את המרחב עבור התקפות סייבר – בעת שהנתונים נאגרים אצל צדדים שלישיים ובממשקים שלהם עם הבנקים.
בשל כך גדל האתגר העומד בפני הבנקים בהיבטי הגנת הסייבר, וכנגזרת מכך גם בהיבטי המשכיות עסקית. בנושא זה, ההוראה קובעת בין היתר את חובת השימוש בפרוטוקולי תקשורת מאובטחים ואת החובה של ספק צד ג' להזדהות בפני מקור המידע באמצעות תעודה חתומה דיגיטלית שהונפקה על ידי ממשל זמין, לצורך פעילות בבנקאות פתוחה ("סרטיפיקט").
הביקורת צריכה לרכוש את המומחיות הנדרשת על מנת לבחון את אפקטיביות התהליכים והאמצעים הטכנולוגיים הננקטים לאימות חזק של לקוחות וצדדי ג', קיום תקשורת מאובטחת, וקיום מנגנוני ניטור התראה ותגובה אפקטיביים ויעילים.
סיכום
על מנת להיות אפקטיבית ורלוונטית, הביקורת נדרשת להיערך ליישום הבנקאות פתוחה. במקביל להיערכות התאגידים הבנקאיים, פונקציות הביקורת הפנימית נדרשות לפתח או להאיץ פיתוח של יכולות וכלים לבחינה של טכנולוגיות ומתודולוגיות פיתוח חדישות, להבנה של מערך היחסים והכללים שחלים על השחקנים/השותפים בתהליכי הבנקאות הפתוחה, ושל הסיכונים ואמצעי ההגנה הנדרשים ליישום. הדבר מהווה תנאי לכך שהביקורת הפנימית תוכל לספק הערכה בלתי תלויה ולהמשיך להביא ערך לארגון.