2014-10-03 08:24:42 +0000 2014-10-03 08:24:42 +0000
78
78

Почему банки не дают доступ ко всей Вашей транзакционной деятельности?

В эпоху больших данных я нахожу удивительным, что банки и компании, выпускающие кредитные карты, предлагают доступ только к нелепому небольшому количеству транзакций - часто только за последние 180 дней, если это так. Самое длинное, что я видел, это 720 дней назад. Я подозреваю, что они все хранят, но намеренно ограничивают доступ.

Эти транзакции только текстовые, занимают очень мало места, и хранение жизни человека транзакции займет меньше 10 МБ данных; о хранении, требуемом для двух MP3 файлов, и около 250k записей на человека за жизнь, если мы щедро предположим, что каждый делает 10 транзакций в день. Но я был бы доволен только последними 10 годами транзакций, так что около 1МБ на клиента. Один из крупнейших банков, JP Morgan Chase, имеет ~70MM клиентов кредитных карт . Это означает 70 ТБ данных за 10 лет записей - едва ли впечатляюще для корпорации такого размера, с $17B из чистых доходов в 2013 году , когда 1 ТБ облачного хранилища стоит 10$ розничной торговли в месяц .

Для сравнения: вы бы смирились с тем, что Gmail или любой другой провайдер электронной почты хранит только самые последние 120 дней? (А электронная почта занимает намного больше места, чем транзакции, гораздо больше по количеству и должна быть мгновенно восстановлена).

Требования к хранению для транзакционной деятельности тривиальны в эпоху, когда мы бросаем вокруг петабайт и зетабайт.

Есть ли веская причина, по которой банки не предоставляют доступ ко всем вашим транзакциям, кроме устаревшего программного обеспечения на их стороне?


UPDATE: Каким-то образом я не нашел этот вопрос 2011 года Quora и спрашиваю то же самое.

Ответы (11)

62
62
62
2014-10-03 13:28:36 +0000

“Всё так, как есть, потому что у них так получилось.”
- Джеральд Вайнберг

Банки в бизнесе уже _очень долгое время. Тем не менее, большая часть того, что мы воспринимаем как само собой разумеющееся с точки зрения технологии (возможностей, мощности и стоимости), является относительно недавним развитием.

Банки часто застревают на старых платформах (например, мейнфреймах), где стоимость резервного онлайн-хранилища намного превышает цену товара, которую потребители воспринимают как само собой разумеющееся. Аналогичным образом, усовершенствование программного обеспечения, требующее внутренних изменений, может быть более сложным. Кроме того, если не сделать ни одного доллара (или миллиарда), банки, как правило, двигаются медленно по сравнению с остальным деловым миром. Преодоление “но мы всегда так делали” является невероятным препятствием в такой крупной, авторитетной организации, как банк - и поэтому в целом ситуация не улучшается без больших усилий. У меня были друзья, которые работали в технологических отделах больших банков.

Маленький банк с меньшими историческими техническими долгами и организационными накладными расходами мог бы с большей вероятностью решить подобную проблему, но я сомневаюсь, что крупнейшие банки потеряют из-за этого хоть какой-то сон.

37
37
37
2014-10-03 20:31:33 +0000

Все остальные ответы здесь верны, но я добавлю еще одну перспективу. Я бизнес-архитектор одного из крупнейших в мире розничных банков. Каждый день я испытываю разочарование от попыток заставить масштабные корпоративные IT делать что угодно, поэтому я чувствую, что ваш вопрос - всего лишь одна из граней более широкого вопроса: “Почему банки так стары и разорены?”

Хотя это правда, что стоимость онлайнового, избыточного, производительного, защищенного хранилища данных значительно выше, чем вы ожидаете в этом вопросе, оно все же должно быть в пределах емкости крупного предприятия. Истинная стоимость - это стоимость изменений.

Ничто в банке не является “зеленой” разработкой. Все является дополнением к существующим системам. Любое изменение влечет за собой риск того, что существующая функциональность будет затронута, поэтому обширные схемы регрессивного тестирования (в основном выполняемого вручную) возникают вокруг даже самых тривиальных разработок. Затраты масштабируются экспоненциально с увеличением количества затрагиваемых платформ (часто совершенно разные, десятилетиями несовместимые платформы, возникшие в результате исторических слияний и поглощений). Одобряются только законодательные, приносящие доход и критически важные изменения в техническом обслуживании.

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

Этот ультранизкий инновационный подход является прямым результатом рыночных и регуляторных сил. Если бы вы были довольны банковским счетом, который играл быстро и свободно с вашими деньгами так же, как Facebook играет с вашими данными, то банковские услуги были бы намного дешевле, намного более инновационными и намного более рискованными. 0x2 и 0x2 и ## Вывод 0x2 и Чтобы вернуться к вашему конкретному вопросу, некоторые банки на самом деле do предлагают гораздо более длинный обратный каталог сделок для скачивания (как правило, только несколько ключевых полей каждой сделки, хотя), и те, которые, скорее всего, не видят в этом точки продажи, и поэтому он падает выше их аппетита к инновациям.

17
17
17
2014-10-03 14:41:44 +0000

Я бы сказал, что многие ответы здесь не совсем верны.

Главная проблема здесь в том, что банковский сектор является высоко олигополизированной отраслью - здесь мало ключевых игроков (в Великобритании, например, всего 5 крупных банков работают под разными брендами: под ними одни и те же компании), и на рынок очень, очень сложно выйти из-за огромной регуляторной нагрузки.

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

Также учтите, что когда у вас есть эта токсичная “голая-минимальная” форма конкуренции, вопрос для этих людей вскоре переходит к вопросу “что нам сойдет с рук?”, в результате чего такие вещи, как низкокачественные онлайн-порталы с таким количеством информации, которое вам нравится, доставляются на бумаге за огромную плату, и вымогательство, цена фиксированная административный сбор. Кроме того, ваша история транзакций - это полезная информация. Есть одна или две высокодоходные компании, которые собирают данные о международных сделках и единственная работа которых заключается в том, чтобы ограничить доступ к этой информации для тех, кто предложит наибольшую цену. Ваша история транзакций является активом в многомиллиардной промышленности в год, и поэтому неудивительно, что банки не хотят выдавать его бесплатно.

14
14
14
2014-10-03 10:15:44 +0000

Одна из причин, по которой они ограничивают его, это чтобы защитить тебя. Если я взломаю твой счет, то получу всю твою финансовую историю. 0x2 и 0x2 и я вижу копию каждого чека, который вы когда-либо выписывали. Я вижу номер счета с каждым врачом, коммунальными услугами и кредитной картой. Я также вижу информацию об аккаунте на обратной стороне тех чеков для всех ваших родственников, которым вы прислали $10 на их день рождения. 0x2 и 0x2 и я могу использовать информацию по этим счетам, чтобы увидеть, где вы раньше жили, это позволяет мне подделывать вас при подаче заявления на новый кредит. Если они спросят, жил ли я когда-нибудь на Мэйн-стрит в Anytown USA. Я могу с уверенностью сказать “да”.

Если я разрешаю вам загрузить только окно времени, то вы обязаны защитить те данные, которые находятся перед окном. Они защищают их в файлах, изолированных от интернета, и, наконец, только в архивных хранилищах.

Некоторая информация не существует в электронном виде. Данные 1990-х и более ранних годов могут не существовать в той форме, в которой вы хотите. Со временем они расширяют окна. Я могу посмотреть/загрузить pdf моего ежемесячного отчета за 7 лет. Конечно, эти данные не могут войти напрямую в ускоренную версию.

Некоторые места позволяют получить файл, который уходит далеко назад, но они берут с вас плату за это, и это может быть сделано только путем отправки вам файла. Это не позволяет вам загружать всю вашу историю каждый день. В это время 70 миллионов клиентов будут перегружены своим сервером и другой инфраструктурой.

Что касается количества данных:

  • Мой ускоренный файл с данными за последние 10 лет составляет около 60 Мбайт и растет.
  • Вы также предполагаете, что единственные данные находятся в текстовых файлах. В них также хранятся электронные копии чеков.
  • Вы также предполагаете, что данные, которые вы видите на транзакции, являются единственными данными, которые существуют относительно транзакции. В них есть поля, которые отслеживают людей, которые обрабатывали транзакцию, местоположение транзакции (банкомат, кассир, почта, отсканированные…), информацию о том, когда она была переведена в другой банк, когда средства были высвобождены….
10
10
10
2014-10-03 08:31:40 +0000

Хотя если считать только ваши данные, то это было бы гораздо меньше 10 МБ, умножьте это на 1 миллион клиентов, и вы увидите, как быстро растут данные. Банки хранят данные в течение более длительного периода времени в соответствии с законодательством страны, как правило, в диапазоне от 7 до 10 лет.

Стоимость хранения данных в режиме онлайн довольно высока в 5-10 раз по сравнению с хранением данных в режиме офлайн. Существуют и другие аспекты: время восстановления после сбоев, чем больше данных, тем больше времени они хранятся. Следовательно, через некоторое время Банки перемещают данные в Архив, которые дешевле для хранения, но недоступны для онлайн-запросов, плюс хранилище не оптимизировано для поиска. Таким образом, поиск этих данных часто занимает несколько дней, если регулятор требует или суд или любой другой подлинный запрос на поиск данных.

8
8
8
2014-10-04 13:06:44 +0000

Чтобы добавить технические подробности к другим ответам, ваша (и некоторых комментаторов) оценка хранения этих данных надежно (на много порядков) отключена.

Давайте возьмем ваши 10 МБ данных по транзакциям на пользователя.

  1. Вы оцениваете только текстовые записи, как в Quicken.

  2. Вы оценивали с помощью потребительских решетки дешево хранения (которые Facebook может позволить себе для своих данных, так как они не хранят транзакции данных). Теперь перейдем к жестким дискам корпоративных серверов. Ваши затраты на хранение данных выросли в 2-5 раз. 0x2 и 0x2 и 3. Обычно у вас есть RAID. Так что в два раза больше.

  3. Большинство крупных финансовых учреждений имеют несколько центров обработки данных. Обычно вы храните все копии данных в этих центрах данных для целей DR. Ваш множитель добавил еще 2х-4х 0х2 и 0х2 и 5. Большинство серверов производственных данных имеют несколько копий (сервер Write DB + одна или несколько копий, доступных только для чтения). Умножьте на 2x-4x

  4. За редким исключением, большинство банков не имеют только одного центрального сервера баз данных. Каждое крупное приложение / бизнес-направление будет иметь свою собственную БД, поэтому вы умножаете это на 2x-20x в зависимости от банка, особенно если он пришел в своем размере путем слияния с другими банками и имеет десятки унаследованных систем.

  5. многочисленные резервные копии. Нормативные требования к резервному копированию означают, что вы не просто делаете резервное копирование данных раз в год. Вы делаете это ежедневно, пока данные не будут удалены из БД.

Итак, в низу смета расходов составляет 30*2*2*2*2*2 = 900 раз (3 порядка) только для хранения баз данных live и 3500 раз для расходов на резервное копирование.

В верхней части могли бы быть 50*5*2*4*4*20=16 000 раз ( 4-5 порядков )

В этом диапазоне нет, банку не стоит держать свои транзакции доступными в БД и в Интернете дольше, чем это абсолютно необходимо.

5
5
5
2014-10-03 14:51:27 +0000

Было поднято много хороших вопросов, и я просто свяжусь с ними здесь, для простоты.

Источник: Я работаю в компании, занимающейся обработкой транзакций по кредитным/дебетовым картам, в команде по работе с базой данных и программным обеспечением для обработки данных.

1. Безопасность

См. mhoran_psprep’s answer .

2. Традиция

См. Ответ Криса .

3. Системная целостность

Хотите верьте, хотите нет, но банки не выставляют свою первичную (или вторичную) базу данных на обозрение конечным пользователям. Они не раскрывают конечным пользователям свою самую быструю/надежную базу данных. Хранение данных только x дней в этой сталкивающейся с клиентом базе данных и ограничение диапазона любого одного запроса, любой запрос, выполняемый против нее, с гораздо меньшей вероятностью вызовет общесистемную медлительность.

У них определенно есть архивы баз данных, которые хранятся в автономном режиме, и определенно есть база данных, ориентированная на сотрудников, которая позволяет им запрашивать большие диапазоны данных.

4. No Added Value

Что получит банк, если вы позволите запрашивать полный год транзакций?

4
4
4
2014-10-03 14:12:58 +0000

Гетерогенные архивы

Большая проблема для исторических данных в банковском деле заключается в том, что они не/не могут находиться в одной системе.

Архивы типичного банка будут включать десятки различных архивов, созданных разными компаниями на разных, несовместимых системах. Например, см. http://www.motherjones.com/files/images/big-bank-theory-chart-large.jpg как иллюстрацию слияний и поглощений банков, а также AFAIK, который не включает в себя много мелких сделок. Для любого счета, это 10-летняя история может быть на какой-нибудь другой системе.

Часто при интеграции таких систем достигается компромисс - если банк A приобретает банк B, который ранее приобрел банк C, то если приобретение C было несколько лет назад, то вы можете пропустить интеграцию архивов C в свои онлайн-системы, держать их отдельно и использовать их только тогда, когда/если это необходимо (и минимизировать эту необходимость за счет больших сборов).

Поскольку прайс-лист и сервисы должны быть одинаковыми для всех, то независимо от того, как возникли ваши аккаунты, если 10% архивов - достаточно дорогая проблема для интеграции, то имеет смысл ограничить доступ к 100% архивам старше какого-нибудь произвольного порога.

3
3
3
2014-10-07 14:27:22 +0000

Ну, я знаю, почему Рабобанк в Нидерландах делает это. Я могу вернуться примерно на полтора года назад с моим интернет-банкингом. Но я могу вернуться дальше (до 7 лет) только после того, как свяжусь с банком и заплачу €5,- за транскрипт (один транскрипт содержит около месяца деятельности). 0x2 и 0x2 и мне понадобились транскрипты на год для оплаты моих налогов, и мне пришлось кашлять более 50 евро.

EDIT Похоже, что недавно они изменили свою политику таким образом, что вы можете запросить столько транскриптов, сколько вам нравится, за максимальную стоимость €25,- так что тенденция к более легкому доступу видна.

2
2
2
2014-10-08 12:53:57 +0000

Если Вам необходим доступ к Вашим данным, превышающий доступ в режиме онлайн, Вы загружаете транзакции и управляете архивом самостоятельно. Шесть - восемнадцать месяцев - это, как правило, достаточное время для того, чтобы большинство людей могли управлять своими собственными архивными данными. Большие банки

имеют возможность хранить и извлекать все данные в режиме онлайн. К сожалению, к старым архивам обращаются нечасто. Почему эти записи находятся в режиме онлайн, когда к ним редко обращаются? Резервное копирование данных займет больше времени. Запросы на получение данных займут больше времени. Все займет больше времени только для того, чтобы у вас были записи, к которым 99% клиентов никогда не будут иметь доступа.

0
0
0
2019-12-07 15:17:57 +0000

Ну, некоторые банки видят свет. В их последнем редизайне Alliant Credit Union имеет возможность загружать все операции:

相关问题

8
7
6
5
2