Электронная закладная выдается при ипотечных сделках, содержит данные о недвижимости и залоге, текущего владельца залога. Электронная закладная регистрируется в Росреестре, далее передается банку - депозитарию хранения и банку - депозитарию учета. Как ценная бумага, электронная закладная имеет свою стоимость исходя из оценки риска, закладные объединяются в портфели, которые имеют свой вторичный рынок обращения. При это каждая сделка перепродажи портфеля требует перепроверки всей истории изменений закладной для точной оценки риска.
Возможные технические решения такой задачи: 1) ничего не менять: результат - высокий риск вследствие отсутствия возможности проверить историю по бумагам, низкое обращения на рынке таких бумаг, ипотечные банки имеют ограничения на привлечение средств для снижения ставки ипотеки); 2) сделать централизованную систему: решение задачи, но тогда должен появиться выделенный участник, который хранит и проверяет электронные закладные, монополизирует комиссию за хранение, имеет высокие риски утечки данных по всем ипотечным сделкам; 3) использовать блокчейн - здесь подробней.
Мастерчейн как блокчейн не хранит сами ценные бумаги. Блокчейн содержит смарт-контракты, которые по сути отражают требования регулирования по проверки сделки купли-продажи недвижимости (наличие всех нужных данных, корректностью проведения шагов и прочее), в блокчейн содержится контрольные суммы документов и действий с ними. Для использования электронной закладной банки - депозитарий устанавливает ноду, автоматически смарт-контрактами выполняет учет и хранение закладной, в любой момент времени может иметь всю историю изменений закладной. Т.о. фактически не требуется наличие выделенной инфраструктуры (с n-ным фактором репликации для повышения надежности) и выделенного участника, который является гарантом сохранности.
Спасибо за материал! Будем надеяться, что Райффайзенбанк продолжит делиться своим опытом внедрения блокчейн. Подскажите, а в какой конфигурации используется IPFS? Если файлы нарезаются на куски, нет ли каких-то юридических особенностей (например, филиал 1 хранит банковскую тайну филиала 2)?
Пользуемся Appcelerator в коммерческих проектах. Есть как плюсы, так и минусы. Кроме того, что Вы написали выше по поводу особенностей работы, пришли к нескольких выводам:
1) Appcelerator может эффективно решать 99,9% всех задач в мобильной разработке.
2) В случае «больших» проектов (время чистой разработки больше 3 месяцев) есть риски столкнуться с непредвиденными ошибками, на исправление которых уходит большое количество времени и сил. Особенно, вопросы memory leaks.
Как результат, отличное решение для большинства задач. Однако, для крупных проектов лучше использовать нативные инструменты. К сожалению, найти грань достаточно сложно.
не совсем. appcelerator здесь для примера того, как кроссплатформенные инструменты решают задачу создания уведомлений.
кстати, как раз у appcelerator с этим есть вопросы. например, с переходом на arrow push все приложения должны или мигрировать, или забыть про уведомления.
Спасибо, берем метод в работу :) Вопрос билдов для приложений очень актуален.
На практике, как ни странно, для тестировщика бывает удобно видеть даже не номер сборки, а дату билда. Так и заказчик, и тестировщик в процессе разработки проекта быстро понимают кто на что смотрит.
Да, вопрос по доставке можно обойти, но решить кардинально нельзя. На практике, в большинстве случаев уведомления в приложение носят необязательный характер (новая запись, погода, локация), поэтому в итоге гарантии не требуются.
PushAll не пробовали, но теперь будем держать в голове :)
Попробую пояснить.
Электронная закладная выдается при ипотечных сделках, содержит данные о недвижимости и залоге, текущего владельца залога. Электронная закладная регистрируется в Росреестре, далее передается банку - депозитарию хранения и банку - депозитарию учета. Как ценная бумага, электронная закладная имеет свою стоимость исходя из оценки риска, закладные объединяются в портфели, которые имеют свой вторичный рынок обращения. При это каждая сделка перепродажи портфеля требует перепроверки всей истории изменений закладной для точной оценки риска.
Возможные технические решения такой задачи: 1) ничего не менять: результат - высокий риск вследствие отсутствия возможности проверить историю по бумагам, низкое обращения на рынке таких бумаг, ипотечные банки имеют ограничения на привлечение средств для снижения ставки ипотеки); 2) сделать централизованную систему: решение задачи, но тогда должен появиться выделенный участник, который хранит и проверяет электронные закладные, монополизирует комиссию за хранение, имеет высокие риски утечки данных по всем ипотечным сделкам; 3) использовать блокчейн - здесь подробней.
Мастерчейн как блокчейн не хранит сами ценные бумаги. Блокчейн содержит смарт-контракты, которые по сути отражают требования регулирования по проверки сделки купли-продажи недвижимости (наличие всех нужных данных, корректностью проведения шагов и прочее), в блокчейн содержится контрольные суммы документов и действий с ними. Для использования электронной закладной банки - депозитарий устанавливает ноду, автоматически смарт-контрактами выполняет учет и хранение закладной, в любой момент времени может иметь всю историю изменений закладной. Т.о. фактически не требуется наличие выделенной инфраструктуры (с n-ным фактором репликации для повышения надежности) и выделенного участника, который является гарантом сохранности.
1) Appcelerator может эффективно решать 99,9% всех задач в мобильной разработке.
2) В случае «больших» проектов (время чистой разработки больше 3 месяцев) есть риски столкнуться с непредвиденными ошибками, на исправление которых уходит большое количество времени и сил. Особенно, вопросы memory leaks.
Как результат, отличное решение для большинства задач. Однако, для крупных проектов лучше использовать нативные инструменты. К сожалению, найти грань достаточно сложно.
Нет, не только. В статье Swift и iOS рассмотрены для примера.
кстати, как раз у appcelerator с этим есть вопросы. например, с переходом на arrow push все приложения должны или мигрировать, или забыть про уведомления.
На практике, как ни странно, для тестировщика бывает удобно видеть даже не номер сборки, а дату билда. Так и заказчик, и тестировщик в процессе разработки проекта быстро понимают кто на что смотрит.
PushAll не пробовали, но теперь будем держать в голове :)