Apple ו-Goldman איבדו אלפי ערעורים לתוך מצב שאיש לא ידע שקיים. זה עלה 89 מיליון דולר.

ביוני 2020, Apple הוסיפה טופס לתהליך הגשת הערעורים של Apple Card. דבר קטן. לפני השינוי, הקשת על "Report an Issue", הגעת לשיחת Messages עם Goldman Sachs, והערעור שלך עבר. אחרי השינוי, נאלצת למלא טופס שני ברגע שההגשה הראשונה נכנסה.

הנה מה שהדבר הקטן הזה עשה. אם דיווחת על הבעיה שלך ב-Messages אך מעולם לא השלמת את הטופס השני, המערכת החליטה שהערעור שלך אינו שלם. הוא מעולם לא נשלח ל-Goldman. איש לא חקר אותו. שום מכתב אישור מעולם לא נשלח. ותחת Regulation Z, סעיף 1026.13, רבות מההודעות הראשונות הללו היו הודעות שגיאת חיוב תקפות — מהסוג שנושה מחויב על פי חוק לאשר בתוך 30 יום ולפתור בתוך שני מחזורי חיוב.

אלפים מהם פשוט נותרו שם. הוגשו, אך לא נותבו לשום מקום. באוקטובר 2024, הלשכה להגנת הצרכן הפיננסי (Consumer Financial Protection Bureau) הורתה ל-Apple ול-Goldman Sachs לשלם 89 מיליון דולר על כך, ואסרה על Goldman להשיק כרטיס אשראי חדש ללא תוכנית ציות אמינה. ביליתי חלק ניכר מהקריירה שלי בתוך תפעול ערעורים אצל מנפיק כרטיסים, וכאשר קראתי את הצו הזה לא ראיתי רשלנות. ראיתי מכונת מצבים עם חור בתוכה, וחור שלכל בנק שאני מכיר יש איפשהו בתהליך העבודה שלו עצמו כרגע.

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

הבאג של 89 מיליון הדולר היה מצב, לא טעות

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

בתהליך העבודה של Apple-Goldman היה מצב בר-השגה שניתן לתאר בשורה אחת: הערעור היה במצב FormA_Submitted AND FormB_Pending. מהמצב הזה, לא היה מעבר אל Investigation_Initiated. כלל לא. צרכן שעצר לאחר ההודעה הראשונה חי שם לצמיתות — זכאי לאישור על פי חוק, לא זכאי לדבר על פי ההיגיון של המערכת עצמה.

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

כשהצוות שלי עבר על זה לראשונה על לוח מחיק, מהנדס אמר את הדבר המובן מאליו — שזה היה סתם באג, מהסוג שהיינו תופסים בבדיקות. שאלתי אותו איך. תהליך Apple-Goldman היה נקודת אינטגרציה אחת בין שתי מערכות. לרוב המנפיקים הגדולים שעבדתי איתם יש 10 עד 15 מערכות שנוגעות בערעור בודד — פורטל Visa VROL, ה-GCMS של Mastercard, פלטפורמת ניהול התיקים, ספר החשבונות הבנקאי המרכזי, מערכת יצירת המכתבים, הזנת לשכת האשראי, מנוע האשראי הזמני, וחופן תורי ניתוב פנימיים. כל שינוי API, כל אינטגרציה של שותף, כל תכונת מוצר חדשה פותחת נתיבים חדשים דרך המבוך הזה.

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

למה לא יכולנו פשוט לכתוב עוד בדיקות?

איבדתי אחר צהריים שלם לוויכוח הזה, אז הרשו לי לחסוך לכם את אחר הצהריים.

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

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

זה הרגע שבו התחלתי לקרוא על שיטות פורמליות ברצינות, ולטכניקה שחשובה כאן יש תיאור פשוט. בודק מודלים לוקח מודל של תהליך העבודה שלך ואינווריאנט — תכונה שחייבת תמיד להתקיים — ואז הוא חוקר כל מצב בר-השגה, באופן ממצה, בחיפוש אחר אחד שבו התכונה נשברת. כתוב את האינווריאנט כ"כל ערעור שהוגש מגיע לאישור בתוך 30 יום", כוון את הבודק אל תהליך Apple-Goldman, והוא יחזיר את המצב המת בתוך שניות, יחד עם הנתיב המדויק צעד-אחר-צעד שמביא אותך לשם. כלים כמו TLA+ עושים זאת עבור מערכות מבוזרות; אותו היגיון חל באופן נקי על תהליך מפוקח עם מועדים קשיחים.

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

התנגשות לוחות הזמנים שאיש אינו אחראי לה

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

ערעור בודד על כרטיס דו-רשתי יכול להפעיל שלושה או ארבעה שעונים רגולטוריים ורשתיים בו-זמנית. Reg Z דורש אישור בכתב בתוך 30 יום ופתרון בתוך שני מחזורי חיוב, בתקרה של 90. Reg E, המסדיר שגיאות חיוב והעברות אלקטרוניות, פועל על פי לוח זמנים שונה לחלוטין — אשראי זמני ופתרון בתוך 10 ימי עסקים, עם הארכה של 45 ימים קלנדריים. Visa Claims Resolution מריץ תיקי Allocation עד 70 יום ותיקי Collaboration עד 100. מסגרת הערעורים של Mastercard נמשכת בין 45 ל-120 בהתאם למחזור, והתעשייה תיארה את הפריסה שלה כקשה עוד יותר לעיכול מזו של Visa.

כאשר המשטרים הללו מתנגשים על ערעור אחד, הציות מסתכם במי שבמחלקת הערעורים זוכר איזה מועד חל באותו בוקר. ראיתי אנליסט בכיר מיישם את תזמון Reg E על שגיאת חיוב לפי Reg Z כי השניים מיטשטשים יחד תחת עומס — ובלבול מדויק זה הוא אחת מההפרות שבוחני CFPB מחפשים. Citizens Bank קיבל ציטוט, בין היתר, על דחיית הודעות שגיאת חיוב בשל תצהיר חסר. המועדים אינם רכים. הם בינאריים. או שאישרת בתוך 30 יום או שלא.

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

בניתי את הדבר הלא נכון תחילה

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

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

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

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

משיכת הכתפיים הזו עלתה לנו בבנייה מחדש, וזה היה הדבר הטוב ביותר שקרה למוצר. השוק צפוף בדבר שבניתי תחילה. FINBOA עוקבת אחר מועדי Reg E ומאוטמת אשראי זמני; היא טובה בזה. Quavo מאוטמת עיבוד ערעורים ומציגה מספרים אמיתיים — איגוד אשראי אחד הגיע לשיעור אוטומציה של 87% בתוך חודש. FIS מעבדת ביטולי חיוב דרך פורטלי הרשתות. כל אחת מהן מאוטמת או צופה בערעורים שנכנסים למערכת. אף אחת מהן אינה מוכיחה שערעור אינו יכול לאבוד לפני שהוא נכנס.

מי עוד באמת מוכיח משהו?

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

השם הרציני היחיד הוא Imandra. הם עושים אימות פורמלי אמיתי בשירותים פיננסיים — הוכחות מתמטיות לנכונות — ובין לקוחותיהם נמנית Goldman Sachs עצמה. אבל עולמם הוא שוקי ההון: לוגיקת התאמת בורסה, פרוטוקולי מסחר. ציות צרכני, Reg Z, תהליכי ערעור — זה לא מה שהם מכוונים אליו, ועם כ-5 מיליון דולר בסך גיוסים הם לא כיוונו לשם.

בינתיים ההון נשפך אל הפינה האחרת של הציות. Bretton AI, לשעבר Greenlite, גייסה סבב Series B של 75 מיליון דולר בפברואר 2026 ומשרתת בנקים המפוקחים על ידי OCC — עבור KYC, מניעת הלבנת הון, וקליטת לקוחות. פלטפורמת Sensa של SymphonyAI הפחיתה תוצאות חיוביות שגויות בסינון הסנקציות של בנק ספרדי ב-91.8%. Alloy מתזמרת זהות על פני יותר מ-800 מוסדות. כסף אמיתי, הנדסה אמיתית — כל זה מכוון לפשע פיננסי ולקליטת לקוחות, שום דבר מזה לא לשאלה האם פתרון הערעורים שלך יכול להפר רגולציה.

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

המשפט שבנה מחדש את המצגת שלנו

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

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

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

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

האם זה לא מוגזם עבור תור ערעורים?

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

הראשונה היא עלות. אימות נשמע כמו פרויקט מדעי, והחלופה הייעוצית — חברת Big 4 שמעצבת מחדש את התהליך שלך — עולה בין 500 אלף דולר לכמה מיליונים ומוסרת לך תהליך מעוצב מחדש שאיש לא בדק מתמטית. הצב את זה מול הצד השלילי. Apple-Goldman היה 89 מיליון דולר. צו ההסכמה של Wells Fargo, על פני כשלים מרובים כולל טיפול בערעורים, הגיע ל-3.7 מיליארד דולר. אינך קונה אימות מול העלות של רישיון SaaS; אתה קונה אותו מול הזנב.

השנייה היא "נפח הפעילות שלנו בסדר". צפוי שביטולי חיוב גלובליים יגיעו ל-337 מיליון בשנה עד 2026 ולטפס ב-24% עד 2028, עם סוגי ערעורים חדשים לחלוטין המגיעים — כולל ערעורים מסוכני AI אוטונומיים שקונים דברים שלקוחות מעולם לא אישרו. המחלקה הידנית ש"מטפלת בזה" היום היא אותה מחלקה שבה 42% מהמוסדות עדיין מריצים ציות על תהליכים ידניים, לפי דוח הרבעון הראשון של 2026 של Wolters Kluwer. נפח עולה בתוספת זיכרון ידני הם הדרך שבה מצב מת נותר בלתי מורגש במשך ארבע שנים.

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

במה אני מאמין כעת

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

אז השאלה שהייתי מציב לכל מי שמנהל מחלקת ערעורים אינה "האם האנשים שלך זהירים". היא צרה וקרה מזו: האם אתה יכול לשרטט את המצב שבו הערעור הנשמט הבא שלך ימות? אם אינך יכול לשרטט אותו, אינך יכול לבדוק אותו, ואם אינך יכול לבדוק אותו, הדבר הכן היחיד שנותר הוא להוכיח שהוא אינו יכול להתקיים. זו העבודה — להוכיח שתהליכי הערעורים שלך אינם יכולים להפר את Reg Z, Reg E, ואת לוחות הזמנים של הרשתות, בכל נתיב, לפני שבוחן מוצא את זה שהחמצת. אם זו הוודאות שאתה באמת צריך, זה מה שאנחנו בונים.

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