העברות IP/IP ו-IPZip

IP to IP (IPIP)

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

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

1. אבטחה: העברות מכתובת IP לכתובת IP עלולות להיות פחות מאובטחות בהשוואה לרשתות בנקאיות מבוססות, כגון SWIFT או ACH, המיישמות שכבות אבטחה, הצפנה ואימות מרובות. תקשורת ישירה בין שתי כתובות IP עלולה לחשוף מידע רגיש לאיומי אבטחה אפשריים, ובהם פריצה, דיוג או התקפת אדם-בתווך.
2. אמינות: השימוש בהעברות מכתובת IP לכתובת IP אינו מבטיח את אמינות העסקה, שכן אין בענף הבנקאות תקנים או פרוטוקולים מוכרים באופן אוניברסלי להעברות מבוססות IP. הדבר עלול להוביל לבעיות בעיבוד העסקאות, במעקב אחריהן ובהתאמתן.
3. ציות: בנקים ומוסדות פיננסיים כפופים לתקנות ולדרישות רבות, ובכללן מדיניות למניעת הלבנת הון (AML) והכרת הלקוח (KYC). ייתכן שהעברות מ-IP ל-IP אינן עומדות בדרישות רגולטוריות אלה, ועלולות לחשוף את הצדדים המעורבים לסיכונים משפטיים ופיננסיים.

במקום העברות מכתובת IP לכתובת IP, בנקים ומוסדות פיננסיים מעדיפים להשתמש ברשתות מבוססות, כגון SWIFT, RTGS או ACH/תשלומים מיידיים, ובתקני מסרים כגון ISO 20022, כדי להקל על העברות כספים מאובטחות, אמינות ותואמות רגולציה בין מוסדות שונים.

ההבדלים העיקריים בין שרתי תקשורת לבין שרתי ספר חשבונות/חשבונות בבנקים

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

שרתי תקשורת

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

1. החלפת נתונים מאובטחת: שרתים אלה מאפשרים החלפת נתונים מאובטחת, ומבטיחים כי מידע פיננסי רגיש יועבר בין מוסדות מבלי להיפגע.
2. פרוטוקולים וסטנדרטים: הם משתמשים בפרוטוקולים סטנדרטיים כגון SWIFT, SEPA או ACH וכדומה לתקשורת בין-בנקאית, ובכך מבטיחים אחידות ואמינות בין פלטפורמות שונות.
3. הצפנה ואימות: לשמירה על האבטחה, שרתי התקשורת משתמשים בשיטות הצפנה מתקדמות ובפרוטוקולי אימות מחמירים, המגנים על הנתונים במהלך העברתם.
4. טיפול בעסקאות: בראש ובראשונה, הם מטפלים בבקשות עסקה, בהודעות ובהוראות, ומשמשים מתווכים המעבירים את המידע הדרוש לביצוע העסקאות.
5. אין העברת כספים: חשוב לציין כי שרתים אלה אינם מעבירים כספים ואינם מעדכנים יתרות חשבון באופן ישיר; הם מאפשרים אך ורק את התקשורת הנדרשת לפעולות כאלה.

שרתי פנקסים/חשבונות

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

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

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

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

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

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

העברת IP ZIP

העברה מאובטחת מבוססת קבצים של הוראות תשלום מוסדיות

העברת IP ZIP מובנת בצורה הטובה ביותר כשיטה מאובטחת מבוססת קבצים להעברת הוראות תשלום מובנות ונתוני עסקה נלווים ישירות בין מערכות מוסדיות מאומתות באמצעות רשת פרוטוקול אינטרנט.

המינוח מחייב דיוק מיוחד.

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

בהתאם לכך:

IP ZIP מעביר מידע והוראות תשלום. הוא אינו מסלק כספים בעצמו.

מבחינה מושגית, הדבר דומה להבחנה החלה על הודעת ISO 20022 pacs.008 (העברת אשראי של לקוח בין מוסדות פיננסיים). הודעת pacs.008 יכולה לשאת הוראת העברת אשראי בין-בנקאית בעלת מבנה מפורט, אך אין לבלבל בין ההודעה עצמה לבין התנועה והסילוק הסופיים של כסף בנק מרכזי, כסף בנקים מסחריים או יתרות בחשבונות קורספונדנטיים.

אותו עיקרון חל על שידור ZIP באמצעות IP.

2. קובץ ה-ZIP כמיכל עסקאות מאובטח

רכיב ה-ZIP משמש בעיקרו כמנגנון מכולה ואריזה.

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

בהתאם למפרט הדו-צדדי המוסכם, חבילה כזו עשויה לכלול:

• הוראות תשלום מובנות;
• הודעות תשלום בפורמט XML;
• מערכי נתונים תואמי ISO 20022;
• אובייקטי עסקה בפורמט JSON;
• רשומות עסקאות בפורמט CSV או בפורמט קבוע;
• קבצי תשלומים בין-בנקאיים קנייניים;
• פרטי החייב והנושה;
• פרטי חשבון המוצא והמוטב;
• מזהי עסקאות;
• פרטי המטבע והסכום;
• מועדי הביצוע ומועדי הערך המבוקשים;
• הוראות בנק קורספונדנט;
• פרטי הבנק המתווך;
• פרטי התשלום (remittance information);
• פרטי ניתוב לסליקה;
• תיעוד ציות;
• אסמכתאות KYC או KYB;
• מידע על מקור הכספים;
• דפי פירוט עסקאות;
• חתימות דיגיטליות;
• פונקציות גיבוב קריפטוגרפיות;
• תעודות;
• חותמות זמן;
• קובצי התאמה; וכן
• סכומי ביקורת.

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

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

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

3. הוראת תשלום מובנית

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

לדוגמה, מוסד יכול להעביר הוראת XML המכילה שדות התואמים למידע המצוי בדרך כלל בהודעת ISO 20022 מסוג pacs.008, ובכלל זה:

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

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

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

לפיכך:

קבלת הוראה ≠ קבלת כספים

הוראה שאומתה ≠ כספים שנסלקו

קובץ שיובא בהצלחה ≠ המוטב זוכה בכספים סופיים

אישור השרת ≠ אישור סליקה

הבחנה זו היא יסודית לאופן שבו IFB מתייחס לשיטות העברה חלופיות.

4. פרוטוקולי העברה

יש לבצע העברות IP ZIP מוסדיות אך ורק בסביבת תקשורת מבוקרת ומאומתת.

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

SFTP

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

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

FTPS

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

HTTPS / REST API

ניתן להעביר את החבילה באמצעות נקודת קצה מאומתת מסוג HTTPS או ארכיטקטורת API תוך שימוש ב-TLS ובאימות מתאים ברמת היישום.

Mutual TLS

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

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

VPN

ניתן להקים מנהרה פרטית מוצפנת בין המוסדות המשתתפים באמצעות VPN מסוג IPSec או מקביל לו מסוג אתר-לאתר, בטרם תתבצע ההעברה ברמת היישום.

קישוריות פרטית ייעודית

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

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

5. אימות נקודות קצה

על המוסד המקבל לוודא שההעברה אכן מקורה במוסד שבשמו היא מוצגת.

הבקרות הרלוונטיות עשויות לכלול:

• אישורים דיגיטליים מוסדיים;
• זוגות מפתחות ציבוריים/פרטיים של SSH;
• אישורי TLS הדדיים;
• אישורי גישה ל-API;
• רשימת היתרים של כתובות IP;
• אימות VPN;
• מודולי אבטחה חומרתיים;
• הצמדת תעודות (certificate pinning) במקום שהדבר מתאים;
• אימות ניהולי רב-גורמי;
• חשבונות שירות מבוקרים;
• בקרות גישה מבוססות תפקידים; וכן
• הפרדה בין סביבות ייצור לסביבות בדיקה.

כתובת IP בלבד אינה ראיה מספקת לזהותו של מוסד.

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

6. הצפנה

בדרך כלל יש לקבוע סודיות ביותר מרמה אחת.

הצפנת תעבורה

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

הדבר מגן על מידע במהלך העברתו.

הצפנת מטען

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

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

הצפנה במנוחה

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

ההצפנה, לעומת זאת, מבססת סודיות. היא אינה מבססת את תקפותה הפיננסית של העסקה.

7. שלמות קריפטוגרפית

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

לפיכך ניתן להפיק גיבוב קריפטוגרפי (hash) עבור החבילה או עבור הקבצים המרכיבים אותה.

לדוגמה:

חבילת העסקה המקורית
← נוצר גיבוב קריפטוגרפי
← החבילה מועברת
← מערכת הקבלה מחשבת גיבוב באופן עצמאי
← הגיבוב המחושב מושווה לגיבוב שהועבר או שנחתם

אי-התאמה מצביעה על כך שהחבילה שהתקבלה אינה זהה מבחינה קריפטוגרפית לחבילה שאומתה במקור.

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

8. חתימות דיגיטליות

חתימה דיגיטלית ממלאת תפקיד שונה מהותית מזה של הצפנה.

הצפנה מגינה על הסודיות.

גיבוב (Hashing) מסייע בהבטחת שלמות הנתונים.

חתימה דיגיטלית שיושמה כראוי יכולה לסייע בביסוס:

1. אותנטיות - החבילה נחתמה באמצעות המפתח הפרטי הרלוונטי;
2. שלמות - הנתונים החתומים לא שונו לאחר מכן; וכן
3. אחריותיות - ניתן לשייך את החתימה לאישור המוסדי הרלוונטי, בכפוף למסגרת ה-PKI והממשל התאגידי החלה.

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

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

9. הגנה מפני הפעלה חוזרת וכפילות

העברת קבצים פיננסיים מחייבת בקרות למניעת הגשה חוזרת ונשנית של אותה הוראה תקפה.

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

• מזהי הודעה ייחודיים;
• מזהי עסקה ייחודיים;
• חותמות זמן;
• מספרי רצף;
• מזהי קבצים;
• זיהוי הודעות כפולות;
• בקרות אידמפוטנטיוּת;
• פנקסי סטטוס עיבוד; וכן
• התאמה מול הוראות שעובדו בעבר.

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

10. אימות קבצים

קבלה מוצלחת של קובץ צריכה להפעיל אימות, ולא סליקה אוטומטית.

סביבת עיבוד מאובטחת עשויה להכפיף את החבילה למספר בקרות עוקבות:

שלב 1 – אימות ההעברה

אישור כי החבילה הגיעה דרך ערוץ מורשה.

שלב 2 – אימות נקודות קצה

אישור המערכת המשדרת ופרטי ההזדהות המוסדיים.

שלב 3 – בקרות נגד תוכנות זדוניות ואבטחת קבצים

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

שלב 4 – אימות קריפטוגרפי

אימות של ערכי גיבוב (hash), חתימות ואישורים.

שלב 5 – אימות מבני

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

שלב 6 – אימות סמנטי

אישור כי שדות התשלום החובה קיימים ועקביים זה עם זה.

שלב 7 – אימות העסקה

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

שלב 8 – אימות ציות

בקרות AML, סנקציות, KYC/KYB, ניטור עסקאות ובקרות רלוונטיות אחרות.

שלב 9 – אימות הסדר התשלום

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

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

11. אישור קבלה אינו סילוק

סביבת IP ZIP עשויה להפיק מספר אישורים טכניים.

לדוגמה:

ACK – הקובץ התקבל

הדבר מבסס אך ורק כי נקודת הקצה המקבלת קיבלה את החבילה.

ACK – הקובץ אומת

הדבר מבסס כי בקרות האימות הושלמו בהצלחה.

ACK – הקובץ אומת

הדבר מבסס כי החבילה עמדה באימות המבני או הטכני החל.

ACK – ההוראה התקבלה

ייתכן שהדבר מבסס כי הוראת התשלום נכנסה לתהליך העיבוד של המוסד המקבל.

אף אחד ממצבים אלה אינו מעיד בהכרח על:

סולק

הסילוק מחייב אירוע פיננסי נפרד.

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

12. הסדרת העסקה הבסיסית

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

בהתאם למטבעות, למוסדות ולתחומי השיפוט המעורבים, הסליקה עשויה להתבצע באמצעות:

• בנקאות קורספונדנטית;
• חשבונות נוסטרו/ווסטרו;
• חשבונות בנק מרכזי;
• תשתית RTGS;
• מערכות סליקה מוכרות;
• מערכות תשלומים מקומיות;
• תשתיות תשלומים מיידיים;
• בנקים קורספונדנטיים לסילוק; או
• הסדר סליקה אחר המוכר מבחינה משפטית ותפעולית.

14. עקרון האבטחה

IFB מיישם הבחנה יסודית על כל שיטות ההעברה החלופיות:

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

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

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

15. מסגרת הקבלה של IFB

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

לפני הקמת קישוריות בסביבת הייצור, IFB רשאי לדרוש אימות של:

• מוסד המקור;
• סמכות מוסדית להעביר את העסקה;
• הבעלות הנהנית והצדדים לעסקה;
• מקור הכספים והלגיטימיות שלהם;
• התכלית הכלכלית הבסיסית;
• תשתית שליחה וקבלה;
• בעלות על נקודת הקצה;
• ארכיטקטורת IP ורשת;
• שיטת האימות;
• תעודות ואישורים קריפטוגרפיים;
• תקני הצפנה;
• פורמט הקובץ והסכמה;
• מבנה הודעת התשלום;
• מתודולוגיית זיהוי העסקאות;
• פרוטוקול אישור קבלה;
• בקרות כפילות והשמעה חוזרת (replay);
• טיפול בחריגים;
• הליכי התאמה;
• קשרי קורספונדנטים;
• חשבונות סילוק;
• הסדרי נזילות; וכן
• מסלול הסליקה הסופי.

יכולת פעולה הדדית טכנית בלבד אינה מספיקה.

IFB לא תראה בהעברה מוצלחת של חבילת IP ZIP קבלת כספים. העסקה מושלמת מבחינה פיננסית רק כאשר הערך המתאים נסלק בהצלחה באמצעות תשתית הבנקאות או הסליקה המוסכמת, וניתן לבצע התאמה של הסליקה באופן עצמאי.

עיקרון יסוד

IP ZIP הוא השידור המאובטח של הוראה. הסילוק הוא תנועת הערך הכספי המקביל.

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

במינוח הבנקאות המוסדית:

שידור הודעה ← אימות ← תיקוף ← קבלה ← ביצוע ← סילוק ← התאמה

רק השלמת הליך הסליקה הרלוונטי מבססת כי הרגל הכספית של העסקה הושלמה.

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

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

אם ברצונך לדעת עוד על אופן העברת כספים או נכסים לחשבונותיך אצלנו, אנא צור קשר עם Marie Mayer.