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

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

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

  1. חוק מסחר אלקטרוני
  2. הצהרה בנקאית

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

----

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

למערכות רישום יש מגבלות 

בעבר, מערכות דוא"ל תמכו רק בשמונה תווים עבור המזהה (כלומר השם המופיע לפני הסמל @ בכתובת דוא"ל). כתוצאה מכך, אנשים נאלצו לקטוע את שמם הפרטי ואת שם המשפחה שלהם כדי להשתלב בתעודת הזהות. כלומר, היו כתובות דוא"ל כמו ravindrn@microsoft.com (בן דוד שלי, שהיה אחד מ-2000 העובדים הראשונים של מיקרוסופט) ו-anilgods@ibm.com (הלקוח שלי, שהוא ותיק של IBM). (שתי הודעות האימייל שונו כדי להגן על הזהות.)

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

מערכות החיוב נמצאות במורד הזרם

שטרות והצהרות לא נוצרים מהיסוד. במקום זאת, הם מורכבים מנתונים שנשלפו ממערכות סראונד בנופי ה-IT של בנקים, קמעונאים וחברות בתעשיות אחרות. כלומר, הם כפופים לאמרה הישנה של מדעי המחשב: GIGO - Garbage In, Garbage Out. בעוד שעיצוב מחדש של חשבונות והצהרות יכול לשפר את המראה והתחושה שלהם, הוא לא יכול לפתור את בעיית הקריאה הבסיסית הנגרמת על ידי טקסט סודי/חסר/משובש המתקבל ממערכות במעלה הזרם.

מערכות סראונד משתרעות על מספר חברות

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

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

    הודעות פוגעניות
    לבני זוג לשעבר!)
  2. דליפות, מגבלות וגיבוש נתונים על ידי מערכות במעלה הזרם.
  3. ניתוקים הנגרמים ממספר הפרוטוקולים המשמשים להעברת הודעות בין מערכות שונות, למשל. ISO 8587, SWIFT MT, ISO 20022. לכל פרוטוקול יש תכונות משלו מבחינת אורך שדה, תמיכה בתווים מיוחדים וכו'. כתוצאה מכך, הקריינות שהזין המשלם במערכת הבנק שלו אינה בהכרח הקריינות שראתה המוטבת בדוח חשבונות הבנק שלה. אני חושד שהדבר גרם לאי-פענוח של דף חשבון הבנק בדוגמה השנייה.
  4. זהה לעיל עבור מוצרים שונים, למשל. ISO 8587 עבור ATM, SWIFT MT עבור תשלומים חוצי גבולות, ISO 20022 עבור Waiting for Godot. כתוצאה מכך, הקריינות שראה המוטב משתנה לפי שיטת התשלום, למשל. קריינות NEFT שונה מקריינות IMPS גם כאשר המשלם השתמש באותה קריינות מהצד שלו בזמן שיזם את שני ה-MOPs, כפי שהודגש ב-

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

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

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

----

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

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

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

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

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

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

----

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

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

הם מושכים על ידי הון סיכון במרדף הזה.

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

עם זאת, כפי שראינו לעיל, אי-פענוח אינה בעיה קלה לפתרון.

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

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

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

@gtm360: בורות עשויה להיות סגולה עבור סטארט-אפים בתעשיות מוסדרות רבות. כפי שאמר פעם ריד הופמן, "אילו ידענו על כללי הונאה בכרטיסי אשראי, לא היינו מקימים את PayPal".

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

----

אבל הכל לא אבוד.

יש ז'אנר חדש של סטארט-אפים של ETL שמבטיח להשתמש בטכניקות AI/ML מתקדמות כדי לשפר את איכות הנתונים הנקלטים על ידי מערכות במורד הזרם, למשל.
FlatFile ו
OneSchema.

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

AI / ML הוא מאוד ספציפי לתחום. אם כלי ה-ETL הללו יעבדו על מערכות תיעוד בבנקאות, מסחר אלקטרוני ותעשיות אחרות, אולי הם יוכלו סוף סוף לפתור את בעיית אי הפענוח ולקחת את קריאות החשבונות וההצהרות לשלב הבא.

בול זמן:

עוד מ פינקסטרה