הערות שטח

מדריך לקונה: פלטפורמות neobank בסימן מסחרי של הלקוח

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

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

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

הקו השימושי ביותר להתוות הוא בין החלק שחייב להיות נכון לבין החלק שחייב להיות שלכם. הליבה יקרה לטעות בה: פנקס חשבונות בשיטת רישום כפול, חשבונות ויתרות, KYC ו-onboarding, הנפקת כרטיסים ועיבודם, מסילות קריפטו ו-stablecoin, וקונסולת המפעיל שמאחורי הכול. שכבת האפליקציה היא מה שהלקוח נוגע בו: המותג, המסכים, ארכיטקטורת המידע, תת-קבוצת היכולות שהופעלה. פלטפורמה ששווה לקנות חולקת ליבה אחת בין כל המותגים ומגדירה את האפליקציה לכל tenant. הערכו את השתיים על צירים שונים — שפטו את הליבה לפי נכונות: האם הפנקס הוא באמת רישום כפול, האם ההתאמה מחזיקה, האם מפעילים באמת יכולים להפעיל אותה; ושפטו את שכבת האפליקציה לפי גמישות: עד כמה מותג יכול להתרחק לפני שמישהו צריך לעשות fork.

היכן יושב הרישיון — והאם אפשר להפריד אותו

ההרשאה להחזיק כסף או להעביר אותו מוסדרת בחוק, והיא אינה אותה רכישה כמו התוכנה. שאלו בפשטות אם הפלטפורמה כוללת הרשאה מוסדרת או מצפה שתביאו משלכם — ואם היא כוללת, של מי הרישיון, באילו מדינות, והאם אתם לקוח ישיר שלו או הסוכן שלו. הפרדה היא מה שחשוב לקונה: פלטפורמה שמלחימה את התוכנה שלה לרישיון יחיד שאי אפשר להחליף בחרה בשקט את תחום השיפוט ואת השותף שלכם, ואילו פלטפורמה שרואה ברישיון מסילה שאתם מביאים מאפשרת לבחור את ההרשאה בנפרד ולהחליף אותה בהמשך. אף אחת מהן אינה שגויה, אבל חייבים לדעת מה קונים. Protocore Pay (/products/pay) היא שכבת התוכנה לבדה — היא רצה מעל כל מסילה מוסדרת שתביאו, ושום תוכנה אינה רישיון. המושגים שתפגשו בשיחה הזאת — EMI, payment institution, agent, sponsor bank — מוסברים ב-/glossary.

כמה עמוקה מערכת העיצוב

כל ההבטחה של white-label היא שהאפליקציה נראית כמו שלכם, לא כמו שינוי עור של הדמו של הספק — וההבטחה הזאת עמוקה רק כמו מערכת העיצוב שמתחתיה. מערכת רדודה מאפשרת להחליף לוגו וצבע הדגשה. מערכת עמוקה חושפת את אוצר המילים עצמו — צבע, טיפוגרפיה, עיגול פינות, ריווח, צפיפות, תנועה — כ-tokens שכל מסך קורא, כך שמותג הוא קבוצת עקיפות ולא fork. שאלו כמה tokens יש ומה הם מכסים, האם אותם tokens מופקים ל-web, ל-native ולדסקטופ כך שצבע הוא צבע אחד בכל מקום, והאם מעצב יכול להרחיק tenant הרבה מגרסת הייחוס בלי לגעת בקוד. מערכת העיצוב של Protocore (/products/pds) היא תשובה אחת שכבר נשלחה — 144 tokens ו-889 מחלקות utility, dark-first, רדיוס אפס כברירת מחדל, מופקת ל-web, ל-.NET ול-native — אבל שאלת הקונה היא הכללית: האם שכבת העיצוב היא מערכת tokens אמיתית, או שכבת צבע על אפליקציה קבועה?

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

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

הפשרה בין בנייה לרכישה, בכנות

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

אתם אף פעם לא קונים neobank. אתם קונים ליבה שאתם מקווים שהיא אינסטלציה ושכבת אפליקציה שאתם מתכוונים להפוך לשלכם — וכל ההערכה היא להחליט אם הספק התווה את הקו הזה איפה שהייתם מתווים אותו.
— Protocore · Platform engineering

חמישה כיוונים, לא חמישה מוצרים

בקשו מספק דוגמאות ולעיתים קרובות יציגו לכם קומץ אפליקציות מוגמרות. קראו אותן נכון: אלה כיוונים שאותה ליבה יכולה לקחת, לא תפריט שבוחרים ממנו פריט אחד. ליבת הייחוס של פלטפורמה אחת יכולה לעמוד מאחורי בורסה נקייה (Halcyon — מאופקת, המסחר בחזית), סופר-אפליקציה מבוססת צ'אט (Lumen — כסף שזז בתוך השיחה), אפליקציה מבוססת העברות (Fern — תשלומים בקבוצות והמרה לפי כללים קודם כול), build כהה של stablecoin (Volt — ממיין משכורות וכרטיסי צוות), וחשבון רב-מטבעי (Meridian — יתרת EUR לצד USDC, וחשבון BTC שאליו מגיעים תגמולי הכרטיס). חמישה מותגים, חמש ארכיטקטורות מידע, חמישה שילובי יכולות — פנקס אחד, KYC אחד, מעבד כרטיסים אחד מתחת לכולם. המספר שחשוב אינו חמש; הוא כמה tenants הליבה יכולה לשאת. ספק שאומר לכם שהמוצר הוא חמש אפליקציות לא הבין את המוצר של עצמו; ספק שמראה לכם חמש כדי להוכיח שהשישית טריוויאלית מבין אותו.

השאלות שמפרידות בין ספקים

רשימה קצרה חותכת את רוב מצגות המכירה. האם הליבה היא מערכת אחת משותפת או fork נפרד לכל לקוח — וכשבאג מתוקן, האם התיקון מגיע לכל ה-tenants בבת אחת? האם שכבת העיצוב חושפת tokens אמיתיים, או רק מקום ללוגו? האם הפלטפורמה כוללת רישיון רגולטורי, או שעליי להביא אחד — ואפשר להחליפו בהמשך? האם אותה ליבה יכולה לספק גם אפליקציה עצמאית וגם שכבה מוטמעת? אילו חלקים נחשבים בעיניכם תשתית, ואילו אתם מצפים שאבנה בעצמי? התשובות ממקמות ספק על המפה שהמדריך הזה צייר: ליבה משותפת או חוות forks, מערכת tokens או צבע, תוכנה בתוספת הרישיון שלי או חבילה מרותכת, צורת אספקה אחת או שתיים. הפירוק המלא של ליבה כזו — חמשת הכיוונים, אפליקציית ההתייחסות וקונסולת המפעיל שמאחוריהם — נמצא ב-/products/pay, מערכת העיצוב שמתחתיה ב-/products/pds, והמונחים ב-/glossary.

יש מערכת לבנות?

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