Сумерки интересны потому, что очевидный показатель — сколько учетных данных (credentials) система может выдать — может не сказать нам многого о том, действительно ли система работает.

Более значимый вопрос в другом: что происходит после того, как учетные данные уже существуют. Может ли финансовое учреждение использовать их в реальном рабочем процессе, проверить то, что ему нужно, и двигаться дальше, не заставляя того же пользователя проходить очередной раунд проверок?

И вот где дизайн Dusk становится для меня особенно интересным. Вместо того чтобы рассматривать соответствие (compliance) как то, что каждое учреждение должно заново «собирать» внутри собственной изолированной среды, идея заключается в том, чтобы проверенные учетные данные можно было использовать в разных финансовых процессах, сохраняя при этом неизменными лежащие в основе требования.

Но это также создаёт зависимость, которую легко упустить. Dusk нужны не просто люди, которые будут хранить учетные данные; ему нужны независимые учреждения, которым можно доверять, которые понимают информацию, стоящую за ними, и которые действительно встраивают их в свои операции.

Так что выдача учетных данных — лишь отправная точка. Внедрение на самом деле определяется многократным принятием.

Для $DUSK я бы следил за этим гораздо внимательнее, чем за «сырыми» цифрами количества учетных данных.

Сможет ли Dusk сохранить эту модель достаточно простой, чтобы учреждения могли использовать её в масштабе, когда в картину войдут реальный объём транзакций, разные нормативные требования и операционные ограничения?

@Dusk_Foundation $DUSK #dusk