קראתי על הדשבורד הפיננסי שאתם בונים. לפני שנדבר, רציתי לפרוט את הנקודה שהזכרתי בהודעה — הבחירה בין Open Banking ל-Shva. היא לא טכנית בלבד, יש לה השלכות על הארכיטקטורה, העלויות, ולוח הזמנים.
שתי הדרכים העיקריות לחבר דשבורד לנתוני בנקים בישראל. כל אחת פותרת חלק שונה, ולבחירה ביניהן יש השפעה ישירה על מה שאפשר לבנות.
כל לקוח צריך לתת הסכמה שתקפה ל-90 ימים, ולחדש אותה. צריך flow מובנה של בקשת חידוש לפני פקיעה, אחרת פתאום הדאטה מפסיק לזרום. זה המקום שבו פרויקטים מתפרקים אחרי 3 חודשים.
בנק ישראלי מאפשר בדרך כלל 4 שאילתות ליום per customer. אם אתם בונים דשבורד שמתעדכן כל שעה — צריך caching חכם ויום אחרי חידוש הסכמה כל השאילתות חייבות להצליח.
חברה שמנהלת נתוני אשראי של לקוחות נחשבת גוף פיננסי ודורשת רישוי מבנק ישראל (לא רק חברת טכנולוגיה). צריך להסתכל על מבנה משפטי של Finsight — אתם gate או plug-in אצל גוף מורשה קיים?
API של בנק נופל לכמה שעות כל חודש (נתון מהשטח). צריך UX שמראה את זה ברור ומאפשר ללקוח להמשיך לעבוד עם הנתונים הקיימים עד שהחיבור חוזר.
לא פיננסית, אבל עם אותם אתגרים של חיבורים חיצוניים + real-time + consent management.
מערכת ניהול לקוחות עם Supabase realtime, AI insights, ואינטגרציות חיצוניות. הארכיטקטורה: Next.js App Router + Supabase Edge Functions + TypeScript. אותו stack שציינתם — רק מותאם אחרת.
שתי נקודות ממנו שרלוונטיות לכם: מבנה ה-consent tracking והפעלת חידושים אוטומטית (היה חלק מ-CRM לתשלומים חוזרים) וה-pattern של degraded state כשאינטגרציה חיצונית נופלת.
שיחה של 20 דקות. אני רוצה להבין איפה אתם טכנית היום, ומה כבר סגרתם מבחינת רישוי / שותפים. ואז אדע להציע הצעה אמיתית.
Full-Stack Developer ו-AI Specialist. בונה מערכות פיננסיות ודשבורדים בקנה מידה בינוני. הסטאק: Next.js, TypeScript, Supabase, Python לאינטגרציות.