Вполне себе неплохое описание для новичков, но возникает пару вопросов: 1. Зачем описывать контракты API в таблицах, когда уже кучу времени используется openApi спецификация, с возможностью кодогенерации. Представляю лицо разработчика когда он будет переписывать атрибуты body в API с таблицы и их 50+. 2. Откидывать ошибки API на русском языке - интересное, конечно, решение. Но в протоколе HTTP все коды ответа регламентированы и стоит использовать их нейминг. Если вам нужно подкинуть description ошибки - принято писать их на английском языке.
Сейчас, как правило, любое бэк-по это клиентская часть банка, доступная просто автосалону по каким то договорным отношениям.
А если исходить из того, что банк будет предоставлять лишь условные API, позволяющие уже ПО автосалона взаимодействовать с банком то взаимодействие слегка будет другим. Например, сейчас: Автосалон отправляет заявку на кредит, банк самостоятельно принимает решение и говорит о том, что я готов предоставить такой кредит на такой %/срок
В ситуации если автосалон купит BaaS от банка: Автосалон вызывает API банка, проверяя KYC и скоринг потребителя, далее через то же API самостоятельно выбирает тарифы/сроки, ПВ и т.д. на указанный кредит (безусловно, есть некие ограничения со стороны регулятора) и далее свои же деньги выдает в кредит через банк. Банк лишь получает комиссионные за обработку указанного кредита, но все взаиморасчеты потребителя происходят лишь с автосалоном (просто под капотом автосалон использует функционал банка). Это, конечно, лишь мечты. Но тот же Solarisbank в Германии потихоньку к этому пришел.
Если мы исходим из того, что организации нужен кредитный конвейер - сам процесс KYC, скоринга, проверки документов действительно нужно отдать на аутсорс в режиме BaaS организации, имеющей банковскую лицензию. Но тут есть маленькая ремарка: Банк может предоставлять вам информацию в таком режиме лишь о том, что клиент действительно проверен (выполнить KYC), действительно платежеспособен и действительно имеет валидные документы. А далее сам бизнес - процесс того, какой кредит вы хотите выдать потребителю и на каких условиях будет решать сама организация, делающая автокредитование. Для пользователя будет выглядеть так, будто он берет кредит в условном автосалоне, за кредит будет ответственен автосалон, но "хостится" он будет в организации, имеющей банковскую лицензию.
Добрый день) Маркетинг наше все, но все же сокращение придумано не нами. Где то на просторах интернета есть даже обувь BaaS)
Касательно "white label" здесь скорее речь про то, что этот "white label" начал активно заходить на рынок цифровых услуг, в рамках которых компания - вендор продает свои бизнес - процессы целиком предоставляя наружу лишь условное API.
Вполне себе неплохое описание для новичков, но возникает пару вопросов:
1. Зачем описывать контракты API в таблицах, когда уже кучу времени используется openApi спецификация, с возможностью кодогенерации. Представляю лицо разработчика когда он будет переписывать атрибуты body в API с таблицы и их 50+.
2. Откидывать ошибки API на русском языке - интересное, конечно, решение. Но в протоколе HTTP все коды ответа регламентированы и стоит использовать их нейминг. Если вам нужно подкинуть description ошибки - принято писать их на английском языке.
Надеюсь что читали(
Отличные ссылки, чем больше предложим для ознакмления - тем лучше (как мне кажется).
Сейчас, как правило, любое бэк-по это клиентская часть банка, доступная просто автосалону по каким то договорным отношениям.
А если исходить из того, что банк будет предоставлять лишь условные API, позволяющие уже ПО автосалона взаимодействовать с банком то взаимодействие слегка будет другим.
Например, сейчас: Автосалон отправляет заявку на кредит, банк самостоятельно принимает решение и говорит о том, что я готов предоставить такой кредит на такой %/срок
В ситуации если автосалон купит BaaS от банка: Автосалон вызывает API банка, проверяя KYC и скоринг потребителя, далее через то же API самостоятельно выбирает тарифы/сроки, ПВ и т.д. на указанный кредит (безусловно, есть некие ограничения со стороны регулятора) и далее свои же деньги выдает в кредит через банк. Банк лишь получает комиссионные за обработку указанного кредита, но все взаиморасчеты потребителя происходят лишь с автосалоном (просто под капотом автосалон использует функционал банка). Это, конечно, лишь мечты. Но тот же Solarisbank в Германии потихоньку к этому пришел.
Если мы исходим из того, что организации нужен кредитный конвейер - сам процесс KYC, скоринга, проверки документов действительно нужно отдать на аутсорс в режиме BaaS организации, имеющей банковскую лицензию. Но тут есть маленькая ремарка: Банк может предоставлять вам информацию в таком режиме лишь о том, что клиент действительно проверен (выполнить KYC), действительно платежеспособен и действительно имеет валидные документы. А далее сам бизнес - процесс того, какой кредит вы хотите выдать потребителю и на каких условиях будет решать сама организация, делающая автокредитование. Для пользователя будет выглядеть так, будто он берет кредит в условном автосалоне, за кредит будет ответственен автосалон, но "хостится" он будет в организации, имеющей банковскую лицензию.
Альфа Банк и Х5 основали совместное предприятие, которое фактически имеет договорные отношения с теми и другими.
Х5 и Альфа Банк независимые друг от друга предприятия. С тем же успехом можно сравнить ВТБ и Магнит.
СБТ это это ДЗО Сбербанка, что с юридической точки зрения другое.
Добрый день)
Маркетинг наше все, но все же сокращение придумано не нами. Где то на просторах интернета есть даже обувь BaaS)
Касательно "white label" здесь скорее речь про то, что этот "white label" начал активно заходить на рынок цифровых услуг, в рамках которых компания - вендор продает свои бизнес - процессы целиком предоставляя наружу лишь условное API.