Бележки от практиката

Трябва ли ви банков лиценз, за да пуснете fintech приложение?

„Трябва ли ви банков лиценз, за да пуснете fintech приложение?“ всъщност са три въпроса в едно палто. Държите ли парите на клиентите? Движите ли ги? И чие регулаторно разрешение покрива това движение — вашето или на някой друг? Отговорете на тях и въпросът за лиценза до голяма степен се отговаря сам. Краткият отговор, който изненадва повечето екипи: болшинството fintech приложения никога не държат банков лиценз, защото болшинството fintech приложения никога не правят единственото нещо, за което е предназначен банковият лиценз. Следва карта на спектъра, не юридически съвет — целта е да знаете какви въпроси да зададете, преди някой да ви назове срок или цена.

За какво всъщност е банковият лиценз

Пълният банков лиценз — в термините на ЕС, разрешение за кредитна институция — позволява една конкретна, строго охранявана дейност: приемане на депозити от обществеността и отпускане на тези пари като кредити. Това несъответствие на матуритетите, финансирането на дълги кредити със салда, които клиентите могат да теглят по всяко време, е причината банките да носят тежки капиталови изисквания, задължения по гарантиране на депозитите и надзорник, който чете баланса им ред по ред. Ако приложението ви не приема депозити и не кредитира срещу тях, почти със сигурност не ви трябва банков лиценз. Търсите нещо по-леко, по-надолу в спектъра — а спектърът е цялата история.

Спектърът на разрешенията: от най-тежките до най-леките

Финансовите разрешения са на нива. На върха стои кредитната институция — банката, — която може да приема депозити и да отпуска кредити. Под нея дружеството за електронни пари (ДЕП) може да издава електронни пари: може да съхранява средства на клиенти и да ги предоставя в карти или портфейли, но държаните средства трябва да бъдат защитени — отделени и недокосвани, никога отпускани като заем. По-надолу платежната институция (ПИ) може да изпълнява плащания — да инициира преводи, да събира, да изпраща суми, да обслужва картови транзакции като аквайрър, — но не е създадена да съхранява стойност във времето; парите минават през нея, не стоят в нея. И най-отдолу агентът или дистрибуторът изобщо няма собствен лиценз, а действа по разрешението на лицензиран субект, който го е регистрирал.

Закономерността е, че всяка стъпка надолу отнема по една възможност и заедно с нея — част от капитала и задълженията. Приемането на депозити е най-тежкото, което може да ви бъде позволено; да си агент на този, който може, е най-леката позиция. Повечето потребителски fintech приложения — портфейли, карти, преводи, платежни линкове — попадат в обхвата на ДЕП и платежните институции или се изграждат върху партньор, който държи някое от тези разрешения. Много малко от тях трябва да са банки, а ако го осъзнаете рано, ще си спестите много насочени в грешна посока усилия.

Бърз начин да се позиционирате: ако клиентите ви ще държат баланс в приложението — портфейл, който зареждат, или предварително заредена карта, — вие сте в територията на електронните пари, защото съхраняването на стойност е разрешението, което определя ДЕП. Ако парите само преминават — инициирате превод, събирате сметка, препращате директно изплащане, — естественото решение е разрешение за платежна институция, държано от вас или от партньор. Ако изобщо не докосвате средствата и само показвате информация за сметки, водени другаде, дори това има своя по-лека регистрация. Колкото по-тежка е позицията ви, толкова повече капитал и надзор идват с нея; целта при проектирането е да не заставате по-тежко, отколкото продуктът наистина изисква.

Наемане на разрешението: партньорски модели

Не е нужно сами да притежавате разрешението, за да строите върху него. Обичайният път е да го наемете. При договорка със sponsor bank или Banking-as-a-Service лицензирана банка или ДЕП води сметките, издава IBAN-овете и картите и защитава средствата; вие изграждате приложението върху техния API и доставяте изживяването. При агентски модел се регистрирате като агент на платежна институция — или като дистрибутор на издател на електронни пари — и техният лиценз покрива вашата дейност, а регулаторът ви познава чрез тях. Различни договори, един и същ факт: някъде в стека някой държи разрешението. Въпросът е само дали този някой сте вие, или партньор.

Кой каква отговорност носи

Наемането на лиценз не прехвърля отговорността. Лицензираният субект е този, който отговаря пред регулатора — за защитата на средствата на клиентите, за мониторинга срещу изпиране на пари, за поведението на цялата програма. Но тези задължения се спускат надолу по веригата чрез договор. Ако работите с лиценза на партньор, пак ще правите KYC и онбордингa, пак ще следите транзакциите за AML, пак ще спазвате лимитите и отчетността, които обвързват партньора. Отговорността не е толкова прехвърлена, колкото разпределена: партньорът я носи пред регулатора, а вас държи отговорни по договор, който връща голяма част от ежедневните задължения на вашата страна. Четете този договор също толкова внимателно, колкото бихте чели лиценза, който сте избрали да не вземате.

Лицензът е разрешение да държите или движите чужди пари. Софтуерът е начинът, по който тези пари се нареждат, съпоставят и показват обратно на клиента. Можете да ги купите от един доставчик или от два — но винаги купувате и двете.
— Protocore · Инженерство на плащанията

Софтуерът и лицензът са отделни покупки

Това е прозрението, което пренарежда целия проект. За клиента платежното приложение изглежда като едно цяло, но всъщност е две слепени неща: регулираното разрешение да държите или движите пари и софтуерът, който нарежда движението, води книгата, съпоставя постъпленията и показва баланс на екрана. Те се набавят поотделно. Можете да имате собствен лиценз и да купите софтуера; да имате лиценз и да изградите софтуера вътрешно; да наемете разрешението чрез партньор и да купите софтуер отгоре; или да вземете и двете от един доставчик, който ги е пакетирал. И четирите варианта са нормални. Ненормално — и тихо струващо на проектите месеци — е да ги бъркате: да търсите „банков лиценз“, когато всъщност ви трябва BaaS партньор плюс приложение, или да търсите приложение с убеждението, че разрешението идва вградено в него.

Да ги виждате като отделни покупки е изяснява нещата, защото можете да ги остойностявате и планирате независимо. Софтуерът се оценява по достойнствата си — работи ли процесът по онбординг, вярна ли е книгата, могат ли операторите наистина да управляват системата, — докато разрешението се оценява по юрисдикция, защита на средствата и условия. Protocore Pay (/products/pay) е пример за самостоятелен софтуерен слой: whitelabel платформа за приложения и операторска конзола, която работи върху каквито и регулирани релси да ѝ осигурите. Тя не е лиценз и никой софтуер не е — затова именно лицензът остава отделен ред в плана.

Въпроси към всеки доставчик на платформа

Който и да ви предлага платформа от рода на „стартирайте своя fintech“, един и същ кратък списък разсейва повечето неясноти. Включва ли продуктът ви регулирано разрешение, или аз трябва да донеса свое? Ако включва, чий е лицензът, в кои държави, и директен клиент ли съм на този субект, или на неговия агент? Кой защитава средствата на клиентите и къде се държат те? Кой е посочен пред регулатора за борба с изпирането на пари — вие, партньорът или аз? Кои задължения падат върху мен по договор, макар лицензът да не е мой? И ако партньорството приключи, какво се случва с парите и данните на клиентите ми? Отговорите бързо разделят доставчиците на тези, които продават софтуер, на тези, които препродават разрешението на партньор, и на тези, които наистина са пакетирали и двете — и ви казват с кой от трите всъщност говорите.

Успокояващото е следното: повечето приложения стартират като софтуер плюс разрешение на партньор и преминават към собствен лиценз едва когато обемът, марджинът или стратегията оправдаят капитала и екипа по съответствие. Да знаете коя стъпка наистина ви трябва — и че софтуерът и разрешението се купуват на отделни редове — е по-голямата част от битката. Останалото е да зададете горните въпроси и да прочетете внимателно отговорите. Нищо от това не е правен съвет, а праговете и наименованията на категориите се различават според юрисдикцията; приемете го като карта, която носите на разговор с регулатор или консултант, а не като заместител на такъв.

Имате система за изграждане?

Опишете ни проблема. Ще се върнем с архитектура и план.