A fintech szoftverfejlesztést pontosan úgy árazzák és ütemezik, mint bármely más szoftverfejlesztést, egészen addig, amíg valaki fel nem teszi a kérdést, hogy kinek van engedélye a pénzt tartani. Ettől a ponttól a projekt már nem mérnöki feladat, hanem szabályozási feladat mérnöki összetevővel, és az az ütemterv, ami a fejünkben volt, tarthatatlanná válik.
A technológia ritkán a nehéz rész. A pénzmozgatás megoldott probléma, érett szolgáltatókkal, dokumentált felületekkel és tesztkörnyezetekkel, amelyekben már az első napon lehet dolgozni. Egy fintech projektet az engedélyezési helyzet nyújt meg, az auditálhatósági kötelezettségek, és az a tény, hogy több architekturális döntést már meghozott az, aki a licencet birtokolja.
Ez a kérdés szabja meg az ütemtervet: saját engedéllyel rendelkezik, más cég engedélye alatt ügynökként dolgozik, vagy teljesen elkerüli a szabályozott tevékenységet? A három válasz gyökeresen eltérő hosszúságú projekteket eredményez, és a különbséget a várakozás hónapjaiban mérjük, nem a fejlesztés heteiben. Válaszolja meg, mielőtt bármit is felmérne.
Az FCA-engedély a kritikus út
Ha közvetlen engedélyre van szüksége, akkor az eljárás, nem pedig a fejlesztés határozza meg az indulás dátumát.
A brit felügyelet, az FCA törvényi kötelezettsége, hogy a kérelmekről rögzített határidőn belül döntsön, és ezek a határidők nemrég megváltoztak. 2026 januárjától az FCA csökkentette a törvényi határidőit az új cégek engedélyezésére és az engedélyek bővítésére: teljes kérelem esetén 4 hónapra, hiányos kérelem esetén 10 hónapra, a korábbi 6 és 12 helyett. A meglévő üzleti modellhez szorosan illeszkedő bővítéseknél 3 hónapot vállal teljes és 6 hónapot hiányos kérelemre. A vezető tisztségviselőkre vonatkozó kérelmeknél legalább a felét 35 napon belül szeretné elbírálni. Ezek a brit felügyelet határidői, és csak azokra a projektekre vonatkoznak, amelyek a brit rendszer alá esnek.
Két dolog következik ebből. Az óra akkor indul, amikor a kérelem teljes, nem akkor, amikor először benyújtja, tehát a hiányos kérelem gyakorlatilag áll addig, amíg a hiányokat nem pótolja. Az üzleti tervre, a tőkehelyzetre vagy a vezetők alkalmasságára vonatkozó minden egyes visszakérdezés heteket visz el. Ráadásul a javított 4 hónap is hosszabb, mint a legtöbb MVP fejlesztése, vagyis az ésszerű sorrend az, hogy az engedélyezési munkát indítja el először, és mellette épít, nem pedig épít, majd utána kérelmez.
A korai fázisú fintech cégek többsége ezt teljesen elkerüli azzal, hogy egy engedélyezett cég ügynökeként működik, vagy olyan szolgáltatóra épít, amely már rendelkezik az engedélyekkel. Ez legitim és bevett útvonal, és érdemben lerövidíti a piacra jutást. Egyben üzleti függőség is: a terméke valaki más kockázatvállalási hajlandóságán belül él, és annak megfelelőségi csapata a saját ütemtervét is átírhatja.
A fintech szoftverfejlesztés a fizetési csatornákkal kezdődik
Az, hogy melyik fizetési csatornát használja, nem megvalósítási részlet: ez dönti el az adatmodellt, a hibakezelést és az egyeztetési terhet.
A kártyás fizetés gyorsan beköthető, és visszaterheléseket hoz magával, ezért a vitás ügyek teljes életciklusát már az első naptól az adatmodellben kell vezetni, nem később ráaggatva. A Faster Payments másodpercek alatt teljesül, de csak tolásos irányban működik, így a beszedéshez a fizető félnek kell cselekednie, a rendszerének pedig kezelnie kell a várakozást. A csoportos beszedés ütemezetten és megbízhatóan szed be, és felhatalmazáskezelést, sikertelen beszedéseket és garanciasémát hoz magával. Az open banking fizetéskezdeményezést és számlainformációt kínál, erős ügyfélhitelesítéssel és lejáró hozzájárulással, amelyet a rendszerének nyilván kell tartania és meg kell újítania.
A legtöbb termék két vagy több csatornánál köt ki, és a fejlesztési költség éppen ott ül. Egy csatornát egyeztetni egyszerű. Hármat egyeztetni, amelyek mindegyike saját teljesítési időzítéssel, saját hibamódokkal és saját azonosítókkal dolgozik, tekintélyes alrendszer, amit senki nem tervez be, mert kívülről láthatatlan. Idetartozik a napi teljesítési állományok feldolgozása, a díjak és visszaterhelések eredeti tranzakcióhoz kötése, és egy eljárás azokra az összegekre, amelyek semmihez nem köthetők.
Induljon ki abból, hogy a teljesülés aszinkron, az egyeztetés pedig teljes értékű funkció. Azokat a rendszereket, amelyek a fizetést szinkron kérésként modellezik, ami vagy sikerül, vagy nem, az első késve teljesülő fizetésnél át kell építeni.
Mit tesz hozzá a szabályozott szoftver
Négy kötelezettség, amit a hétköznapi szoftver nem visel.
Megváltoztathatatlan naplózás. Egy pénzügyi rekord minden állapotváltozását rögzíteni kell azzal együtt, hogy ki, mit, mikor és miért tett, olyan formában, amit senki nem tud csendben átírni. Ez csak hozzáfűző tervezést jelent a sorok helyben történő módosítása helyett, és ez alakítja az egész sémát.
Ügyfélpénzek elkülönítése, ha pénzt tart. A szabályok szigorúak, a jelentési kötelezettség pedig nagyon konkrét. A cégek jellemzően nem az elkülönítést, hanem a folyamatos jelentést becsülik alá.
Pénzügyi bűnözés elleni kontrollok. Személyazonosság-ellenőrzés, szankciós szűrés és a gyanús tevékenység figyelése. Ennek nagy részét megveszik, nem megépítik, de az integráció, az esetkezelési folyamat és a döntések visszakövethetősége az Öné marad.
Magasabb szintű adatvédelem. A pénzügyi adat érzékeny, a megőrzési időt jogszabály szabja meg, nem a preferencia, a törlési kérelmek pedig úgy ütköznek a törvényi iratmegőrzéssel, hogy azt korán el kell dönteni. A GDPR technikai megfelelésről szóló útmutatónk bemutatja a mechanikát.
Semmi ebből nem egzotikus mérnöki munka. Mindegyik időbe kerül, és mindegyiket be kell tudni mutatni valakinek, aki rá fog kérdezni.
Mennyibe kerül az Egyesült Királyságban
| Felállás | Szokásos sáv | Időtáv |
|---|---|---|
| Ügynöki modell, egy csatorna, saját engedély nélkül | £60 000 és £120 000 között | 3 és 5 hónap között |
| Saját engedély, két csatorna, pénzügyi bűnözés elleni kontrollok | £150 000 és £400 000 között | 6 és 12 hónap között |
| Több csatornás platform, ügyfélpénz, jelentés | £400 000 felett | 12 hónap felett |
Ezek fejlesztési költségek. Az engedélyeztetésnek saját jogi és tanácsadói költsége van, a várakozási idő pedig akkor is égeti a pénzt, ha közben senki nem ír kódot. A testreszabott szoftverfejlesztés költségeiről szóló útmutatónk az általános sávokat járja körül, az egészségügyi szoftver az Egyesült Királyságban pedig ugyanezt a mintát mutatja egy másik szabályozott ágazatban.
A középső sáv az, ami meglepi az embereket. A saját engedély és egy második csatorna nagyjából megduplázza a projektet, és a növekményből szinte semmi nem látszik a felhasználó felé.
Hogyan érdemes sorba rendezni
Először a szabályozási helyzetet tisztázza, írásban, olyasvalakivel, aki erre képesített. Minden későbbi lépés ettől függ, és a válasz megváltoztatja az architektúrát.
Utána építse meg a lehető legkisebb dolgot, ami valódi pénzt mozgat egyetlen csatornán, mert a második csatorna sokkal könnyebb, ha az egyeztetés már létezik. A naplózást és az egyeztetést átvételi kritériumokkal bíró funkcióként kezelje, ne később hozzátett infrastruktúraként, mert egy csak hozzáfűző előzményt utólag beültetni egy olyan rendszerbe, amely sorokat módosít, közel áll az újraíráshoz.
A Mecanik szabályozott pénzügyi szoftvert épít a szoftverfejlesztő csapatával, beleértve azokat a részeket is, amelyekre az auditorok rákérdeznek. Ha a fintech ütemterve abból indul ki, hogy a fejlesztés a leghosszabb elem, érdemes az engedélyezési helyzetet átnézni, mielőtt dátumot vállal.
Kapcsolódó bejegyzések: MVP szoftverfejlesztés: hatókör, költség és ütemterv , Egyedi szoftverfejlesztés az Egyesült Királyságban , Hogyan fejlesszünk webalkalmazást 2026-ban , MI-ügynökök a cégben: költségek és buktatók .
Gyakran ismételt kérdések
Mennyi ideig tart az FCA-engedélyezés? 2026 januárjától a brit felügyelet törvényi határideje teljes kérelemnél 4 hónap, hiányos kérelemnél 10 hónap, a korábbi 6 és 12 helyett. A meglévő üzleti modellhez szorosan illeszkedő bővítéseknél a cél 3 hónap teljes és 6 hónap hiányos kérelem esetén. Az óra akkor indul, amikor a kérelem teljes, nem az első benyújtáskor, így a hiányok gyakorlatilag megállítják.
Mennyibe kerül a fintech szoftverfejlesztés az Egyesült Királyságban? Egy ügynöki modellben működő, egyetlen csatornát használó, saját engedély nélküli termék jellemzően £60 000 és £120 000 között kerül, 3 és 5 hónap alatt. Saját engedéllyel, második csatornával és pénzügyi bűnözés elleni kontrollokkal £150 000 és £400 000 közé kerül, 6 és 12 hónap alatt. Az ügyfélpénzt tartó, több csatornás platformok nagyjából £400 000 körül indulnak.
Kell FCA-engedély ahhoz, hogy fintech terméket építsek? Nem mindig. Sok korai fázisú termék egy engedélyezett cég ügynökeként működik, vagy olyan szolgáltatóra épül, amely már rendelkezik az engedélyekkel, ami a várakozást teljesen kiváltja. A csere ára üzleti függőség: a terméke egy másik cég kockázatvállalási hajlandóságán belül működik, és annak megfelelőségi döntései átírhatják az ütemtervét.
Melyik fizetési csatornát használja egy brit fintech? Ez a pénz irányától és időzítésétől függ. A kártya gyorsan beköthető, és visszaterheléseket hoz. A Faster Payments másodpercek alatt teljesül, de tolásos, így a beszedéshez a fizető félnek kell cselekednie. A csoportos beszedés ütemezetten szed be, és felhatalmazáskezelést hoz. Az open banking fizetéskezdeményezést kínál lejáró hozzájárulással, amelyet a rendszernek követnie kell.
Mire van szüksége a szabályozott szoftvernek, ami a hétköznapinak nincs? Megváltoztathatatlan naplózásra, amely egy pénzügyi rekord minden állapotváltozását rögzíti, az ügyfélpénzek elkülönítésére és annak jelentésére, ha pénzt tart, pénzügyi bűnözés elleni kontrollokra a személyazonosság-ellenőrzéssel és a szankciós szűréssel együtt, és olyan adatvédelemre, ahol a megőrzési időt jogszabály szabja meg. Egyik sem egzotikus, de mindegyiket be kell tudni mutatni.
Hozzászólások