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

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

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

93

מצבים נגישים שנחקרו

מודל פוסט-טפסים מצורף

4 מתוך 4

מאפיינים שהוגדרו נכשלים

אותו מודל סינתטי

יום 6

ההודעה מגיעה למצב סגור ללא מוצא

שעון המודל, לא תיק לקוח

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

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

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

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

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

כיצד פועלת בדיקת המודל

גרף המצבים ותוצאות הכללים נובעים מקוד Python דטרמיניסטי על גבי תהליך העבודה ב-JSON שסופק.

01 / MODEL

קידוד הנתיבים

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

02 / EXPLORE

בדיקת מצבים נגישים

חיפוש לרוחב (BFS) בודק האם מצב של הודעה תקפה יכול להילכד הרחק מחקירה ועוקב אחר נתיבים מול דגלי תזמון שהוגדרו.

03 / REVIEW

הצגת הראיות

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

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

בתוך הסיור המוקלט

קראו את הנתיב, לא רק את הפסיקה

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

01 / COMPARE THE CHECKS

ירוק מתאר נתיב אחד

מערכת המעקב הרגילה עוקבת אחר נתיב הטופס שהושלם ומדווחת על COMPLIANT. חקירת מרחב המצבים שואלת האם ענף נגיש אחר עלול להיכשל. באותו מודל פוסט-טפסים שנבנה היא מדווחת על NON-COMPLIANT מול הכללים שהוגדרו.

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

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

02 / FIND THE BRANCH

הטופס המשני הוא נקודת הפיצול

בגרף, הודעה במודל עוברת ממצב Messages Submitted אל Secondary Form Requested. השלמת הטופס ממשיכה לעבר ניתוב וחקירה. פקיעת זמן מגיעה במקום זאת למצב Closed Incomplete. הבודק חוקר 93 מצבים נגישים ומוצא ארבעה מאפיינים מוגדרים שנכשלו במודל זה שסופק.

תצוגת יישום נקייה של תהליך העבודה הסינתטי פוסט-טפסים: הנתיב האדום מתפצל מ-Secondary Form Requested ל-Closed Incomplete, עם 93 מצבים נגישים וארבעה מאפיינים מוגדרים שנכשלו.
עקבו אחר הענף האדום לאורך גרף המצבים. הוא מסתיים ב-Closed Incomplete בעוד ענף הטופס שהושלם ממשיך ימינה.

03 / INSPECT THE WITNESS

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

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

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

04 / CHECK THE CHANGE

ניתוב מחדש של הטופס הלא-מושלם

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

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

A SECOND WORKFLOW / TIMING

לעיכוב בעיבוד אצווה יש דפוס כשל שונה

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

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

מה כל תוצאה יכולה לאשש

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

נתיב הבדיקהמה שהוא רואה כאןמה שהוא מותיר פתוח
קו בסיס של מסלול מיטביהנתיב הצפוי מדווח COMPLIANT.הוא לעולם אינו חוקר את ענף פקיעת הזמן של הטופס המשני.
חקירת מרחב מצבים93 מצבים נגישים ונתיב ל-ClosedIncomplete ללא חקירה במודל פוסט-טפסים שסופק.האם המודל שסופק תואם לתהליך עבודה אמיתי.
מודל מתוקןכל ארבעת המאפיינים שהוגדרו מתקיימים לאורך 153 מצבים נגישים.האם מאפיינים אלה מכסים כל התחייבות או חריג החלים במקרה זה.

מה הדגמה זו אינה עושה

ארבעת תהליכי העבודה ועשרת מערכי הבדיקה להשוואת ביצועים הם מודלים סינתטיים שנבנו להדגמה. לדף אין חיבור חי למערכת בנקאית, לרשת כרטיסי אשראי, למערכת ליבה, למחולל מכתבים או לנתוני צרכנים, והתעודה היא תוצר של בדיקת מודל ולא אישור רגולטורי. שעוני Reg Z ו-Reg E המקודדים מפשטים את כלל שגיאות החיוב של Reg Z ואת כלל יישוב השגיאות של Reg E; תנאי ההודעה שלהם, החריגים והתחולה בפועל דורשים הערכת מומחים. חלונות הזמנים של Visa ו-Mastercard הם ערכים מוגדרים להמחשה, ולא כללי רשת מעודכנים ומאומתים.

שאלות שצוותי מחלוקות וציות רגולטורי שואלים

כיצד ייתכן שמחלוקת עוברת בהצלחה את לוח הבקרה שלנו אם מעולם לא הגיעה לחקירה?

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

האם הסטטוס PROVEN אומר שתהליך המחלוקות שלנו תואם ל-Reg Z או ל-Reg E?

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

האם כלי זה יכול לבדוק את תור המחלוקות החי שלנו או תיקים מרשתות כרטיסי האשראי?

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

מה בדיוק מעניקה בדיקה שנכשלה לצוות הציות שלנו?

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

כיצד המערכת מטפלת בימי עסקים ובמחזורי חיוב?

ההדגמה משתמשת בשעונים מקודדים מפושטים. בדיקת ההכרעה לפי Reg Z מצמצמת את תנאי שני מחזורי החיוב המלאים לתקרה של 90 ימי לוח, ובדיקת 10 ימי העסקים לפי Reg E משתמשת בהמרה קבועה של 7/5 ללא חגים. חריגים, תקופות מוארכות ותחולת הכללים דורשים בדיקת מומחה נפרדת.

האם החיפוש עלול להיעצר לפני שהוא מוצא מועד שהוחמץ?

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

האם מודל AI מכריע האם תהליך העבודה עבר בהצלחה?

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

מחקר טכני

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

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

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

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

הערכת תהליכי עבודה

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

תכנון אימות

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