SWIFT

העברות SWIFT ותקשורת באמצעות הודעות MT ו-MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) היא רשת הודעות מאובטחת המאפשרת למוסדות פיננסיים, כגון בנקים, לשלוח ולקבל הודעות סטנדרטיות בנוגע לעסקאות פיננסיות, כגון הוראות תשלום ואישורים. SWIFT אינה מנהלת חשבונות ואינה מעבירה כספים; היא מספקת אך ורק פלטפורמה מאובטחת ואמינה להחלפת מידע.

העברות SWIFT רגילות משתמשות בסדרה של סוגי הודעות סטנדרטיים המכונים הודעות MT (Message Type). להודעות אלה פורמטים ושדות מוגדרים מראש, המבטיחים שמוסדות פיננסיים יוכלו להבין ולעבד בקלות את המידע הכלול בהן.

הודעות MX (ISO 20022) הן תקן חדש יותר להעברת הודעות פיננסיות המבוסס על XML (eXtensible Markup Language). הן מספקות פורמט עשיר ומובנה יותר, המאפשר חילופי נתונים משופרים ועיבוד ישיר מקצה לקצה טוב יותר. הודעות MX מחליפות בהדרגה את הודעות MT ברשת SWIFT, במטרה לספק יכולת פעולה הדדית ויכולות טיפול בנתונים טובות יותר.

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

Swift 103+ STP (עיבוד ישיר מקצה לקצה)

Swift 103+ STP היה פורמט MT ישן שהותאם לעיבוד ישיר (STP, Straight Through Processing); מאז תום תקופת הקיום המשותף תפקידו מתמלא על ידי הנחיית השימוש pacs.008 STP. עיבוד ישיר מאפשר לבצע את כל תהליך התשלום, מהיזום ועד להסדר הסופי, באופן אלקטרוני ללא צורך בהתערבות ידנית.

מאפיינים נוספים:

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

שיקולים לגבי STP:

1. הזנת נתונים מדויקת: יש להזין את הנתונים בדיוק כדי למנוע עיכובים או דחיות.
2. עמידה בדרישות הפורמט: על הבנקים להבטיח כי דרישות הפורמט של 103+ STP מקוימות בקפדנות.
3. תוכנה ומערכות: על הבנקים להפעיל תוכנות ומערכות מתאימות כדי לטפל ב-STP ביעילות

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

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

העברות SWIFT gpi.

SWIFT gpi (Global Payments Innovation):

SWIFT gpi, שהושקה בשנת 2017, היא יוזמה שנועדה להתמודד עם מגבלות העברות SWIFT המסורתיות באמצעות שיפור המהירות, השקיפות והעקיבות של תשלומים חוצי גבולות. SWIFT gpi מנצלת את פורמטי ההודעות הקיימים MT ו-MX לשיפור שירותי התשלומים. המאפיינים העיקריים של SWIFT gpi כוללים:

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

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

פרמטרים מרכזיים למשתתפים שאינם משתתפי SWIFT gpi

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

משתתפים שאינם gpi מספקים בדרך כלל פרמטרים אלה באמצעות סכמות תשלומים מקומיות, ממשקי API או פורמטים ישנים, והבנק ה-gpi מטפל בתוספות הייחודיות ל-gpi (למשל, יצירת UETR אם לא סופק, אף שהעברתו אינה חובה עבור גורמים שאינם gpi). הדרישות המדויקות עשויות להשתנות לפי תחום שיפוט, מטבע והסכמים דו-צדדיים, אך הפרמטרים המרכזיים נגזרים מההנחיות של CBPR+ (Cross-Border Payments and Reporting Plus) ומתקני ISO 20022. מאז תום תקופת ההתקיימות במקביל ב-22 בנובמבר 2025, הוראות תשלום חוצות גבולות מוחלפות בפורמט ISO 20022; ההפניות לשדות MT הישנים שלהלן ניתנות לצורכי התמצאות בלבד.
1. זיהוי הצדדים (פרטי החייב והנושה)
פרטים אלה מזהים את יוזם התשלום ואת המוטב, ומבטיחים עמידה בהמלצה 16 של FATF בדבר דרישות כלל הנסיעה.

• החייב/הלקוח המורה: שם מלא, כתובת מובנית (רחוב, עיר, מיקוד, מדינה) וזיהוי החשבון (למשל IBAN או מספר חשבון). בהודעות MT 103/MT 202 COV הקודמות מתייחס הדבר לשדה 50a; ב-pacs.008/pacs.009 ל-<Dbtr> ול-<DbtrAcct>.
• נושה/לקוח מוטב: שם מלא, כתובת מובנית וזיהוי החשבון. מתאים לשדה 59a ב-MT103/MT202 COV לשעבר; <Cdtr> ו-<CdtrAcct> ב-pacs.008/pacs.009.
• חייב/נושה סופי (אם רלוונטי): אם הם שונים מהצדדים העיקריים, יש לכלול את פרטיהם לשם שקיפות מוגברת (אופציונלי אך מומלץ למעקב gpi). ממופה אל <UltmtDbtr>/<UltmtCdtr> ב-pacs.008/pacs.009.

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

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

• סוכן החייב: BIC (Bank Identifier Code) או מזהה אחר של הבנק השולח. מקביל לשדה 52a ב-MT 103 לשעבר; <DbtrAgt> ב-pacs.008/pacs.009.
• סוכן הנושה: BIC של הבנק המקבל. מתאים לשדה 57a ב-MT 103/MT 202 COV לשעבר; <CdtrAgt> ב-pacs.008/pacs.009.
• סוכנים מתווכים (אם ידועים): קודי BIC של כל בנק קורספונדנט (עד 3 רמות). מקביל לשדה 56a בפורמט MT הקודם; <IntrmyAgt1-3> ב-pacs.008/pacs.009.
• סוכנים מורים/מונחים: קודי BIC של השולח/המקבל הישיר בשרשרת. שדה אופציונלי, המסייע בשיטות סדרתיות או בשיטת כיסוי (cover).
• סוכנים מורים קודמים (ככל שרלוונטי): בשרשראות מרובות חוליות, עד 3 סוכנים קודמים.

סיבת הדרישה: מבטיח ניתוב תקין דרך בנקים מתווכים; יש להעדיף BICFI על פני שמות לשם דיוק ב-pacs.009 COV.

3. פרטי העסקה
רכיבים פיננסיים מרכזיים לצורך סילוק.

• סכום ומטבע: סכום הסילוק הבין-בנקאי וקוד המטבע לפי ISO 4217 (למשל USD, EUR). מתמפה לשדה 32A ב-MT 103/MT 202 COV הקודמים; <IntrBkSttlmAmt> ב-pacs.008/pacs.009.
• סכום ההוראה (אם שונה): הסכום המקורי לפני ניכויים.
• מועד סילוק בין-בנקאי: מועד הערך לסילוק. מתאים לחלק משדה 32A ב-MT; <IntrBkSttlmDt> ב-pacs.008/pacs.009.
• שיטת סילוק: יש לציין אם באמצעות RTGS (CLRG), כיסוי (COVE) או סוכן (INDA/INGA). אין מקבילה ישירה ב-MT, אך היא משתמעת.

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

4. מזהי הפניה ומעקב
לצורך עקיבות, ובפרט ב-gpi.

• זיהוי מקצה לקצה: אסמכתא המקשרת את כל השרשרת (למשל מזהה חשבונית או עסקה). <EndToEndId> ב-pacs.008/pacs.009.
• מזהה הוראה: אסמכתת השולח (מוגבלת ל-16 תווים ב-MT). מתאימה לשדה 20 ב-MT הקודם; <InstrId> ב-pacs.008/pacs.009.
• מזהה ייחודי להעברה מקצה לקצה (UETR): מזהה UUID למעקב מקצה לקצה. חובה ב-pacs.008/pacs.009 וכן, ב-MT 103/MT 202 לשעבר, בשדה 121; אם הערוץ היוזם אינו מספק אותו, הבנק הראשון בשרשרת הפועל ברשת Swift מפיק אותו.
• מזהה עסקה: אסמכתה פנימית נוספת.

מדוע נדרש: מאפשר מעקב וקישור של gpi (למשל pacs.008 ל-pacs.009 COV); ה-UETR הוא המפתח לאישורים אוניברסליים.

5. מטרה ומידע על השירות
מסווג את סוג התשלום.

• קודי Purpose ו-Category Purpose (מטרה ומטרת קטגוריה): קודי ISO (למשל SALA עבור משכורת) המציינים את אופי העסקה. נדרשים במסדרונות מסוימים; <Purp> ו-<CtgyPurp> ב-pacs.008.
• קוד רמת שירות: מזהה את שירות ה-gpi (למשל G001 להעברת אשראי ללקוח ב-gpi); על בנקים שאינם ב-gpi להימנע מלכלול קודים ייעודיים ל-gpi אלא אם הוסכם על כך. מתאים לשדה 23E ב-MT; <SvcLvl> ב-pacs.008/pacs.009.
• קוד מכשיר מקומי: עבור מסלולים ייעודיים (למשל, העברות תוך-קבוצתיות).

הסיבה לדרישה: מבטיח ציות רגולטורי ועדיפות בעיבוד; הולך והופך לחובה בעקבות המעבר ל-ISO.

6. העברת כספים והוראות נוספות

• מידע על התשלום (Remittance Information): טקסט חופשי (עד 140 תווים) או מובנה (למשל פרטי חשבונית). מתאים לשדה 70 ב-MT103 לשעבר; <RmtInf> ב-pacs.008/pacs.009.
• הוראות לסוכנים: לדוגמה, /REC/ עבור מקבל, /ACC/ עבור חשבון, או הוראות טלפוניות (PHOB). ממופה לשדה 72 בהודעת ה-MT הקודמת; <InstrForNxtAgt>/<InstrForCdtrAgt> ב-pacs.008/pacs.009.
• אינדיקטורים לזמני סליקה: זמנים מבוקשים (לדוגמה, CLSTm לזמן CLS).

מדוע נדרש: מספק הקשר והוראות טיפול; חיוני לשיטות כיסוי ב-pacs.009 COV.

7. נתונים רגולטוריים ונתוני ציות

• דיווח רגולטורי: קודים או פרטים (למשל מספר זיהוי לצורכי מס, אינדיקטור דיווח כגון CRED/DEB). ממופה לשדה 77B ב-MT; ל-<RgltryRptg> ב-pacs.008/pacs.009.
• קודי סיבת החזרה (אם רלוונטי להחזרות): לדוגמה AC04 לחשבון סגור, ב-pacs.004 המקושר להודעות המקור.

מדוע נדרש: עומד בחובות AML/KYC ודיווח; חובה במסלולים מפוקחים.

לשם יישום מיטבי, על משתתפים שאינם gpi לבנות את הנתונים באופן שימנע קטיעה בעת המרות מ-MT ל-MX, ולהיוועץ בבנק החבר ב-gpi לגבי צרכים ספציפיים. אם התשלום כרוך בשיטות כיסוי, פרטי הלקוח בעסקת הבסיס חייבים להיות זהים בכל ההודעות (למשל, מ-pacs.008 ל-pacs.009 COV).

הודעות תשלום ב-SWIFT gpi

במסגרת SWIFT gpi (Global Payments Innovation), הודעות התשלום המקוריות (למשל pacs.008 להעברות לקוחות או pacs.009 COV להעברות כיסוי) נחשבות בלתי ניתנות לשינוי לאחר שנשלחו. בנקים מקבלים אינם יכולים לשנות ישירות את תוכן ההודעות הללו, שכן הודעות SWIFT מתוכננות לשמור על שלמות ועל יכולת ביקורת לאורך שרשרת התשלום. במקום זאת, כל שינוי, תיקון או ביטול מטופל באמצעות הודעות המשך נפרדות, עדכוני סטטוס דרך gpi Tracker, או שירותים ייעודיים כגון gSRP (gpi Stop and Recall Payment). כך מובטחת עקיבות מקצה לקצה באמצעות מזהה העסקה הייחודי מקצה לקצה (UETR).

בנקים מקבלים (הפועלים בדרך כלל כסוכן הנושה או כמתווך) רשאים, עם זאת, להגיב לבקשות לשינוי מצד השולח או ליזום פעולות שמובילות הלכה למעשה לשינוי בתוצאת התשלום (למשל החזרות או עיכובים). הם רשאים גם לבקש מהשולח הבהרות או תיקונים בתנאים מסוימים. תהליכים אלה כפופים לספרי הכללים של SWIFT, להנחיות נוהג שוק (למשל של Payments Market Practice Group – PMPG) ולדרישות רגולטוריות, תוך מתן עדיפות לאוטומציה, לשקיפות ולמניעת הונאות.

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

• שגיאות בפרטי התשלום: אם קיימים אי-דיוקים, כגון חשבון מוטב שגוי (למשל חשבון סגור – קוד AC04), מטבע שגוי (קוד CURR), ניתוב סוכן שגוי (קוד AGNT) או תקלות טכניות (קוד TECH), רשאי הבנק המקבל להשהות את התשלום ולבקש מהשולח למסור פרטים מתוקנים או לשלוח תשלום חדש. כך נמנעת דחייה מוחלטת תוך מתן אפשרות לפתרון.
• אי-יכולת ליישם את התשלום: לפי הקוד CUTA (Cancel Upon Unable to Apply), אם לא ניתן לזכות את החשבון בתשלום עקב אי-התאמות (למשל אי-התאמה בשם או בחשבון, או פרטים חסרים), הבנק המקבל רשאי לבקש מהשולח פרטי ביטול או תיקון לצורך הסדרת המצב.
• חשד להונאה או לעסקאות בלתי מורשות: במקרה של הונאה (קוד FRAD), הבנק המקבל יכול לזהות בעיות באופן עצמאי ולהתחיל בהשבת הכספים ללא בקשה מוקדמת מהשולח. הוא יכול גם להשיב לבקשות החזרה של השולח על ידי הקפאת הכספים ובקשת שיפוי (קוד INDM) אם הכספים כבר זוכו, כדי לצמצם את הסיכון לפני ההשבה.
• תשלומים כפולים או שלא כדין: קודים כגון DUPL (תשלום כפול) או UPAY (תשלום שלא כדין) מאפשרים לבנק המקבל לסמן את העסקה ולבקש את ביטולה אם היא שגויה או בלתי מוצדקת.
• סוגיות רגולטוריות או סוגיות ציות: אם התשלום מפר חוקים מקומיים, סנקציות או דרישות AML (קוד LEGL), הבנק המקבל רשאי לדחות אותו או לעכבו ולבקש מהשולח מסמכים נוספים או תיקונים.
• החלטות הלקוח או המוטב: אם המוטב מסרב לקבל את התשלום (קוד CUST או NOAS – אין מענה מהמוטב), הבנק המקבל רשאי להחזירו ולהודיע לשולח, ואף לבקש אישור לשינויים.
• החלטות תלויות ועומדות: במקרים תלויים ועומדים (קוד PDCR), כגון המתנה לאישור חיוב (RQDA) או למענה מהסוכן הבא (PTNA), הבנק המקבל רשאי להחזיק את התשלום ולבקש הוראות נוספות או שינויים כדי להמשיך בביצועו.

בכל המקרים יש לבנות את הבקשות באופן המאפשר אוטומציה (למשל, באמצעות הכללת UETR, אסמכתאות מקור כגון שדה 20/32A/50/59 וקודים ספציפיים בשדה 79 של ההודעות) לצורך תמיכה בעיבוד ישיר מקצה לקצה (STP). ייתכן שיידרשו הסכמי שיפוי דו-צדדיים אם כספים מזוכים, ולבנק המקבל אין חובה לקבל בקשות, אולם עליו לתעדף בקשות דחופות (למשל, הקשורות להונאה).

תהליכים מעורבים

• מענה לבקשות החזרה ביוזמת השולח: השולח (בנק החייב) יוזם בדרך כלל בקשת החזרה באמצעות MT 192/292 (או מקבילות ISO 20022 כגון camt.056) דרך שירות gSRP, הנשלחת באופן טורי או ישירות לבנק המקבל. על הבנק המקבל לאשר קבלה באופן מיידי ולהשיב באמצעות MT 196/296 (או MT 199/299 אם ההודעה מובנית), תוך שימוש בקודים כגון CNCL (בוטל), RJCR (נדחה עם סיבה) או PDCR (ממתין). אם הבקשה מתקבלת, הכספים מוחזרים באמצעות pacs.004 (החזר תשלום).
• פעולות עצמאיות של הבנקים המקבלים: אם מתגלה הונאה בתוך הבנק המקבל, הוא רשאי להחזיר את הכספים באמצעות pacs.004 עם פרטים מובנים, ולהודיע באמצעות ה-Tracker לצורך עדכוני סטטוס בזמן אמת.
• בקשות לתיקון/הבהרה: הבנקים המקבלים משתמשים בהודעות בירור (כגון MT 195/295) כדי לבקש שינויים, כגון פרטים נוספים. הדבר נפוץ בתשלומים המוחזקים בהמתנה.
• שילוב Tracker: כל הפעולות מעדכנות את gpi Tracker בזמן אמת, בגישה באמצעות ממשקי API או ממשק גרפי, ובכך מובטחת שקיפות לכל הצדדים. חברי gpi חייבים לציית לספרי הכללים המחייבים עבור gCCT (העברת אשראי ללקוח), gCOV (כיסוי) ו-gSRP.
• מגבלות וגורמי הצלחה: אין ערובה לביצוע שינויים; ההצלחה תלויה בשלב התשלום (קל יותר לפני הזיכוי), בשיתוף הפעולה של המוטב ובתחום השיפוט. תקנות גוברות תמיד על הנחיות. אם הזיכוי בוצע, החזרת הכספים מחייבת הסכמת המוטב או כתב שיפוי.

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

הפרדה בין העברת הודעות לסילוק ב-SWIFT gpi

SWIFT gpi מטפל בעיקר בהוראות תשלום ובמעקב אחריהן באמצעות מסרים (למשל תבניות ISO 20022 כגון pacs.008 להעברות לקוח, pacs.009 להעברות פיננסיות, או MT 103/MT 202 מהמערכת הקודמת), אך התנועה הממשית של הכספים מתרחשת בנפרד, ברמת הסילוק. הסילוק מתבצע בדרך כלל באמצעות יחסי בנקאות קורספונדנטית (חשבונות נוסטרו/ווסטרו), קיזוז דו-צדדי או מנגנוני סליקה וסילוק (CSM) כגון מערכות סילוק ברוטו בזמן אמת (RTGS) (למשל T2, לשעבר TARGET2, באירופה, Fedwire בארצות הברית, או CHAPS בבריטניה). ה-gpi Tracker מספק נראות בזמן אמת לסטטוס המסר, אך העברת הכספים נשענת על מערכות היסוד הללו.

תקופת הדו-קיום להוראות תשלום חוצות גבולות הסתיימה ב-22 בנובמבר 2025: הוראות תשלום כגון MT103 ו-MT202 הוחלפו בהודעות ISO 20022 (MX) כגון pacs.008 ו-pacs.009, ואילו קטגוריות MT אחרות יופסקו במועדים מאוחרים יותר. להלן הסבר כיצד מתבצעים החזרים ושחרורי עיכוב ברמת החשבון, הסליקה והסילוק.

כיצד מוחזר הכסף ברמת החשבון, הסליקה וההסדר
החזרות מתחילות לאחר בקשת החזרה מוצלחת (באמצעות gSRP – שירות gpi Stop and Recall Payment) או לאחר זיהוי עצמאי (למשל הונאה, טעויות). שירות gSRP משתמש בהודעת camt.056 (בקשה לביטול תשלום) מצד השולח, המקבלת מענה בהודעת camt.029 (תוצאת בירור). לאחר הקבלה, החזרת הכספים מבוצעת באמצעות הוראת תשלום חדשה המהפכת את הזרימה, מחייבת את חשבון הבנק המקבל ומזכה בחזרה לאורך השרשרת. אין זה שינוי של ההודעה המקורית אלא עסקה נפרדת.

שיטות סילוק מרכזיות ותהליכי החזרה
שיטות הסילוק קובעות כיצד מתבצעות ההחזרות:

• CLRG (סליקה באמצעות תשתית שוק): סילוק באמצעות RTGS או CSM (למשל באמצעות בנק מרכזי). החזרות משתמשות ב-pacs.004 כדי להורות לתשתית השוק לחייב את חשבון הסוכן המקבל ולזכות את חשבון הסוכן הקודם, לעיתים בזמן אמת או באותו יום.
• INGA (הסוכן המורה מסלק ראשון): השולח מסלק את הכספים לפני שליחת ההודעה. החזרות באמצעות pacs.004 מחייבות את חשבון הסוכן המקבל את ההוראה לאחר הסליקה.
• INDA (הסוכן המונחה מסלק עם קבלת ההודעה): הצד המקבל מסלק עם קבלת ההודעה. אם הסליקה לא בוצעה, ההודעה נדחית באמצעות pacs.002 (ללא תנועת כספים); אם הסליקה בוצעה, הכספים מוחזרים באמצעות pacs.004.
• COVE (שיטת הכיסוי): משמשת לתשלומים בסכומים גבוהים עם העברת כיסוי (pacs.009 COV). ההחזרים עוקבים אחר השרשרת ההפוכה: pacs.004 מסוכן המוטב חזרה לבנקים המתווכים, תוך חיוב וזיכוי חשבונות הקורספונדנטים בהתאם.

הליך ההחזרה שלב אחר שלב ברמת הסילוק

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

2. הוראת החזרת כספים: הצד המקבל מנפיק pacs.004 (החזרת תשלום) או MT 103/MT 202 מסורתיים עם קודי החזרה (למשל RETN). הודעה זו כוללת:

• אסמכתאות מקור (UETR, End-to-End ID, Instruction ID).
• היפוך תפקידים: הנושה המקורי הופך לחייב; סוכן החייב המקורי הופך לנושה.
• פרטי הסליקה: סכום ותאריך הסליקה הבין-בנקאית המקוריים, שער חליפין (אם מעורב מט"ח), עמלות (אם נוכו).
• קוד סיבת החזרה (למשל AC04 לחשבון סגור, FRAD להונאה).
• שדה חשבון הסילוק (אם קיים בהודעה המקורית) לציון החשבון לזיכוי.

3. ביצוע הסליקה:

• הודעת pacs.004 מפעילה חיוב של חשבון הנוסטרו/ווסטרו של הבנק המקבל (המתנהל אצל הסוכן הקודם או אצל MI).
• הכספים מזוכים בחזרה מחוליה לחוליה לאורך השרשרת, באמצעות אותה שיטת סילוק (למשל, העברת RTGS ב-CLRG).
• במקרה של החזר חלקי, יש לציין "PART" במידע הנוסף יחד עם הסכום היחסי.
• ה-Tracker מעדכן את הסטטוס (למשל "הוחזר") בזמן אמת, והוא גלוי באמצעות API או GUI.

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

5. הודעות לאחר ההחזרה: יש להשתמש ב-camt.053/054 (דף חשבון/הודעת חיוב-זיכוי) כדי לאשר את עדכוני הפנקס. אין להשתמש שוב ב-pacs.004 ל"החזרת החזרה": יש להשתמש בבירורים במקום זאת.
ההחזרות מבוצעות באופן אוטומטי ככל הניתן, אך ייתכן שתידרש התערבות ידנית מטעמי ציות או אם הכספים הוקפאו. השבת הכספים אינה מובטחת; היא תלויה בעיקר במהירות שליחת בקשת הביטול ובשאלה אם הכספים כבר זוכו. אם ההסדר טרם הושלם (למשל, דחייה לפני ההסדר), לא מועברים כספים: יש להשתמש במקום זאת ב-pacs.002.

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

עצירה מתרחשת כאשר לא ניתן לעבד תשלום באופן מיידי (למשל עקב שגיאות, בדיקות ציות או המתנה להבהרה), והוא מוצב במצב "ממתין" ללא סילוק. לא מתבצע חיוב או זיכוי של כספים עד לפתרון. ה-gpi Tracker מציג סטטוסים כגון "On Hold" או "Pending" (למשל קוד PDCR), והפתרון נעשה באמצעות הודעות בירור (MT 195/199 או camt.029).

תנאים המובילים להקפאות

• אי-התאמות (למשל אי-התאמה בין החשבון לשם – קוד CUTA).
• בדיקות רגולטוריות (למשל, סנקציות – קוד LEGL).
• ממתין לתגובת המוטב (קוד NOAS) או לאישור חיוב (RQDA).
• שעות לא מקוונות או עיבוד אצווה בבנק המוטב.

תהליך השחרור ברמת הסילוק
1. הודעת עיכוב: הצד המקבל שולח pacs.002 (עדכון סטטוס) או MT 199 עם קוד המתנה, ומחזיק את הכספים בחשבון ביניים/נאמנות אם הסילוק חלקי (למשל בשיטות כיסוי).
2. פתרון: השולח מספק תיקונים/הבהרות (למשל באמצעות תגובת MT 195 או camt.029). אם הנושא נפתר, המקבל נותן "אור ירוק" ומעבד את ההוראה המקורית.
3. ביצוע הסילוק:

• ה-pacs.008/pacs.009 המקורי משוחרר מהשהיה.
• הכספים מוסדרים בדרך שנקבעה: חיוב חשבון השולח, זיכוי חשבון המקבל (למשל באמצעות RTGS ב-CLRG), ולאחר מכן זיכוי סופי בחשבון המוטב.
• שלב המוטב (מהבנק המקבל ללקוח הקצה) הוא לרוב השלב שבו מתרחשים עיכובים, בפרט בשווקים עם בקרת הון או תשתית מוגבלת.
• המעקב מתעדכן ל"זוכה" או "הושלם", ו-pacs.002 (דוח סטטוס תשלום) מאשר זאת.

4. אם לא שוחרר: אם הנושא לא נפתר (למשל לאחר פקיעת מועד), יש להחזיר באמצעות pacs.004 כמתואר לעיל, או לדחות באמצעות pacs.002 (ללא סילוק).

כללי gpi מחייבים זיכוי באותו יום ככל שניתן; Swift דיווחה ב-2018 כי כמעט 50% מתשלומי gpi זוכו בתוך 30 דקות וכמעט 100% בתוך 24 שעות. גורמים כגון פיקוח על תנועות הון או שעות שבהן מערכות הבנק אינן פעילות עלולים להאריך את זמני ההחזקה, אך gpi מדגישה אוטומציה כדי למזער אותם.

SwiftNet Instant

SwiftNet Instant. זוהי פלטפורמת מסרים בזמן אמת בעלת השהיה נמוכה, הזמינה 24/7 ותומכת בחילופין מאובטחים של תזרימי תשלומים מיידיים בין מנגנוני סליקה וסילוק (CSM) לבין משתתפיהם.

לקוחות יכולים להתחבר ל-SwiftNet Instant באמצעות תשתית הקישוריות והאבטחה הקיימת שלהם ב-Swift, לרבות קופסאות VPN, קווים ייעודיים ומודולי אבטחה חומרתיים. השילוב עם סביבת ה-IT של הבנק מתבצע באמצעות Alliance Gateway Instant (AGI).

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

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

חיוב ישיר ב-SWIFT

חיוב ישיר במערכת SWIFT הוא שיטת תשלום המאפשרת לעסקים ולאנשים פרטיים לגבות כספים מחשבונות בנק של חייבים במטבעות שונים ובמדינות שונות. בניגוד ל-SEPA Direct Debit, שנועד במיוחד לאזור SEPA ומוגבל לעסקאות הנקובות ביורו, לחיוב ישיר במערכת SWIFT היקף גלובלי והוא תומך במגוון רחב של מטבעות.

תהליך ייזום עסקת חיוב ישיר במערכת SWIFT כולל בדרך כלל את השלבים הבאים:

1. הסכם בין הנושה לחייב: בין הנושה לחייב חייב להתקיים הסכם קודם, הכולל את התנאים וההגבלות לעסקאות בהרשאת חיוב ישיר. הסכם זה עשוי לכלול גם הקמת מנדט או הרשאה, המתירים לנושה לגבות תשלומים מחשבון הבנק של החייב.
2. חילופי הודעות: הבנק של הנושה יוזם את החיוב הישיר בשליחת הודעת SWIFT לבנק החייב – ב-ISO 20022 הודעת pacs.003 (חיוב ישיר של לקוח) או pacs.010 (חיוב ישיר של מוסד פיננסי), לשעבר MT 104 או MT 204. הודעה זו כוללת את פרטי העסקה, כגון הסכום, המטבע, פרטי חשבון החייב וכל מידע נדרש אחר.
3. אימות והרשאה: בנקו של החייב מאמת את פרטי העסקה, בודק את זמינות הכספים בחשבון החייב ומאשר את ההרשאה לביצוע העסקה. אם הכול תקין, בנקו של החייב ממשיך לחייב את חשבון החייב בכספים.
4. העברת הכספים: הכספים מסולקים בין בנק החייב לבנק הנושה באמצעות חשבונות קורספונדנטים או מערכת סליקה והסדר.
5. אישור: עם קבלת הכספים, הבנק של הנושה שולח לנושה הודעת אישור על ביצוע חיוב ישיר מוצלח.

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

1. חשבונות בנק: על הנושה והחייב כאחד להחזיק חשבונות בנק במוסדות פיננסיים החברים ברשת SWIFT.
2. הסכם והרשאה: נדרשים הסכם והרשאה לחיוב (מנדט) שהוסדרו מראש בין הנושה לחייב, כדי לאפשר ביצוע עסקאות חיוב ישיר.
3. פורמטים של הודעות SWIFT: על הנושה ועל הבנק שלו להשתמש בפורמטים המתאימים של הודעות: pain.008 ליזום חיוב ישיר, ו-pacs.003 או pacs.010 בין בנקים.
4. עמלות בנק: על הנושה והחייב להיות מודעים לעמלות הכרוכות בעסקאות חיוב ישיר במסגרת מערכת SWIFT, שכן עמלות אלה עשויות להשתנות בהתאם לבנקים ולמדינות המעורבים.

RMA בהודעות SWIFT בין-בנקאיות

בעולם הבנקאות והפיננסים, תקשורת מאובטחת ויעילה בין בנקים היא חיונית. כאן ממלא SWIFT (Society for Worldwide Interbank Financial Telecommunication) תפקיד מכריע, ונושא את רוב ההודעות הבין-בנקאיות הבינלאומיות. רכיב קריטי המבטיח את אבטחתה ואת סלקטיביותה של תקשורת זו הוא אפליקציית ניהול הקשרים (RMA).

מהו RMA?

Relationship Management Application (RMA) היא יישום תוכנה של SWIFT המאפשר למוסדות פיננסיים להגדיר אילו צדדים נגדיים רשאים לשלוח להם הודעות SWIFT, ומבטיח שהתקשורת ברשת SWIFT מוגבלת למשתמשים מאומתים בלבד. RMA היא שכבת אבטחה יסודית בניהול התקשורת הבין-בנקאית, שכן היא מסננת הודעות בלתי מורשות ומפחיתה את סיכון ההונאה.

חשיבותו של RMA

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

כיצד פועל RMA

תהליך ה-RMA כולל מספר שלבים עיקריים:

1. יצירת יחסי RMA: לפני ששני בנקים יכולים להתחיל להחליף מידע באמצעות SWIFT, עליהם להסכים הדדית על יצירת RMA. הסכם זה דומה ללחיצת יד דיגיטלית, והוא מבטא אמון והסכמה לתקשר.
2. חילופי מפתחות: כל בנק שולח הרשאת RMA באמצעות יישום ה-RMA, והצד הנגדי מקבל אותה. RMA החליף את חילופי המפתחות הדו-צדדיים הקודמים (BKE); ההודעות עצמן מאומתות באמצעות SWIFTNet PKI (תשתית מפתח ציבורי).
3. הגדרת RMA: כל בנק משתמש בכלי RMA כדי להגדיר הרשאות ולציין אילו סוגי הודעות מתקבלים מהבנק האחר. ניתן לעשות זאת באופן כללי או בהתאמה מדויקת, תוך פירוט סוגי הודעות ותתי-סוגים ספציפיים.
4. הפעלה וניטור: לאחר שהגדרות ה-RMA נקבעו והופעלו, יכולים הבנקים לנטר הודעות נכנסות ולבדוק את עמידתן בהרשאות שנקבעו. RMA מספק גם כלים לשינוי הרשאות או לביטולן, אם צרכים עסקיים או שיקולי אבטחה מחייבים זאת.

יישומים מעשיים

עבור IFB, המתמחה בניהול השקעות ועושר ללקוחות בעלי הון גבוה ולישויות תאגידיות, RMA מספק מספר יתרונות:

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

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

בקצרה

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

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

הוראות פיננסיות דיגיטליות מבוססות בלוקצ'יין של Swift

בספטמבר 2025 הודיעה Swift כי יחד עם למעלה מ-30 מוסדות פיננסיים החלה בתכנון ובפיתוח של פנקס חשבונות דיגיטלי משותף. ב-9 ביולי 2026 הכריזה Swift כי הפנקס מוכן לשימוש ראשוני, ו-17 בנקים מתכוננים להפעלת פיילוט של עסקאות חיות בפיקדונות מוטבעים (tokenised deposits): ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB ו-Wells Fargo. היישום הראשון יתמקד באפשור הוראות חוצות גבולות בין בנקים בזמן אמת, 24/7 – שיפור קריטי במארג עיבוד העסקאות הבין-לאומי.

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

כפי שהסביר חאבייר פרס-טסו (Javier Pérez-Tasso), המנכ"ל של Swift:
"שילוב של פנקס חשבונות משותף עם מערכת ההודעות הקיימת של Swift, עם ממשקי API ועם ISO 20022 יוצר מבנה חזק אף יותר – מבנה שיכול לשלב סיכונים, בקרות ודרישות ציות כבר מראשית זרימות העסקאות, ובו בזמן לאפשר הוראות בין-בנקאיות חוצות גבולות בזמן אמת, 24/7, באותה מידה של אמון, אבטחה, חוסן, יכולת הרחבה ומצוינות תפעולית שבהן ידועה Swift. הכול בהתאם לגישה שנקטנו תמיד, של חדשנות אחראית."

הרחבת התשתית

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

ב-Sibos הדגיש Pérez-Tasso גישה דו-מסלולית זו:
"תשתיות פיננסיות צריכות לשמור על מיקוד בלתי פוסק ביסודות של מצוינות תפעולית, ציות רגולטורי וממשל תאגידי. ובו בזמן עליהן להיערך לעתיד. וב-Swift, הגישה שלנו היא לחדש בשני מסלולים מקבילים."

שיתוף פעולה בכל רחבי התעשייה

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

מבט קדימה

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

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

שאלות נפוצות

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

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

מהם היתרונות?

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

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

מהו מקרה השימוש הראשון?
הוראות עסקאות בין-בנקאיות חוצות גבולות בזמן אמת, 24/7.

מי מעורב?
למעלה מ-30 מוסדות פיננסיים מ-16 מדינות סייעו בעיצוב התכנון; 17 בנקים מפעילים בשלב הניסוי את העסקאות החיות הראשונות.

מתי הוא יהיה זמין?
Swift הכריזה כי ספר החשבונות מוכן לשימוש ראשוני ב-9 ביולי 2026. הבנקים בפיילוט מבצעים עסקאות חיות ראשונות בשלב עלייה לאוויר מבוקר; הסילוק הסופי עדיין מתבצע במערכות הקיימות. הפונקציונליות והזמינות יורחבו בהמשך.

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