Добрый день! Меня зовут Алексей Булавин, я представляю центр компетенций Сбертеха по Big Data. Представители бизнеса, владельцы продуктов и аналитики часто задают мне вопросы по одной и той же теме — матчинг. Что это такое? Зачем и как его делать? Особенно популярен вопрос «Почему он может не получиться?» В этой статье я постараюсь на них ответить.
Начнем с бытового примера. У меня есть маленький сын. Недавно он освоил мобильный телефон и теперь любит таскать его с собой, чтобы, как взрослый, непринужденно позвонить кому-нибудь когда вздумается и поговорить на какую-нибудь «очень важную» тему. Звонит он только маме, папе и бабушке. Больше всего достается бабушке: порой он по 10 раз в день звонит ей, чтобы рассказать, что с ним произошло 5 минут назад.
В детском саду у него есть друг Денис, и у Дениса тоже есть мобильный телефон. Встретившись, они как взрослые меряются телефонами, но никогда не звонят друг другу. Я как-то спросил сына:
— Почему бы тебе не позвонить и не поболтать с другом о том о сем, обсудить свои дела?
— Папа, мне это совсем не нужно, мы и так встречаемся в саду каждый день и, если что, поговорим там. Дела подождут.
Мне стало интересно, как же так? Выяснилось, что просто ни он, ни Денис не знают своего собственного номера телефона и не могут ими обменяться. Налицо отсутствие связи из-за отсутствия ключей.
Новые средства взаимодействия в обществе порождают новые возможности, более тесно связывают людей, а системам указывают об их связанности. Матчинг — это один из типов связанности, который указывает на отношения субъекта с самим собой. Например, когда на разных досках объявлений продается одна и та же машина, а мы хотим связать и воспринимать эти объявления вместе, как единое целое.
Информация сегодня представляет ценность, которую можно монетизировать. Соответственно, дополнительная информация дает дополнительную ценность, увеличение прибыли или сокращение издержек — с помощью разработки новых фич, качественного изменения существующих или вообще создания новых продуктов.
Как правило, наш продукт четко связан с теми или иными объектами, знания по которым мы хотим обогащать. Чем больше дополнительной информации из новых источников мы получаем, тем актуальней становится задача объединения информации из всех источников в единое информационное пространство, как будто это атрибуты одной системы.
Добыть и связать данные — вроде бы стандартная техническая задача. Но из-за ряда проблем это бывает затруднительно или вовсе невозможно:
Люди, организации, объекты – в каждой новой системе все регистрируются заново и получают новые собственные идентификаторы.
Для некоторых типов данных ID присваивается отдельным событиям или сообщениям в потоке, а не тому объекту, который нас интересует. Например, система фиксирует кредитные заявки, и если один и тот же человек оформит две отдельные заявки, то это будет два разных ID. А для самого человека ID в системе не будет.
В идеале каждому уникальному ID соответствует уникальный объект, но на практике это бывает не так. Например, машина сменила цвет или номер ПТС, человек сменил фамилию или пол. По формальным признакам для автоматической системы это новый объект. Также проблема может возникнуть если, например, оператор вместо поиска уже существующей записи в базе просто заводит новую — так ему проще.
Например в социальных сетях, где владелец странички искажает свое имя и фамилию или совсем заменяет их на вымышленные. Можно найти десятки Иванов Ургантов или Владимиров Познеров, и это не однофамильцы.
В разное время для одного и того же ID можно ожидать разные объекты или субъекты. Например, когда у телефонных номеров меняются владельцы.
Получается, что связать объекты двух систем между собой по ключу бывает либо невозможно, либо процент и качество связанности оказываются ниже желаемого уровня. Можно попробовать собрать ключ как комбинацию нескольких информационных полей, составной ключ. Но здесь возникают новые трудности:
Никто не обещает, что обычные информационные поля будут «not null». А дальше как повезет. Чем больше полей в составном ключе, тем больше вероятность, что какие-то ключи не будут получаться.
Например, адрес офиса организации заполняется произвольным образом: д.5 к.2 офис 16; дом 5 корпус 2 офис 16; 5-2-16. Или телефон: +7(495)344-3…, 8-495-344…, 495344….
Кроме того, для информационных полей в составном ключе характерны трудности, которые мы упоминали ранее. Поля, входящие в составной ключ, тоже могут быть не уникальны, ошибочны, преднамеренно искажены и не постоянны.
Как же победить перечисленные выше трудности и добиться 100% матчинга? Начать стоит с вопроса: а действительно ли нужно достигать таких высоких уровней качества? Может, для решения бизнес-задачи вполне достаточно 70%?
Есть у нас составной ключ, состоящий из набора атрибутов. Каждый из них с некоторой вероятностью будет заполнен и с некоторой вероятностью подойдет для применения в качестве элемента ключа. Вероятность что весь составной ключ будет нормален — это произведение всех вероятностей по всем атрибутам ключа. Все это еще нужно умножить на вероятность того, что объект в принципе присутствует в двух системах. Тогда мы получим вероятность матчинга. А умножив ее на общее число сущностей, получим количественный прогноз по сопоставлению.
Чем меньше атрибутов в составном ключе, тем вероятность матчинга выше и при этом ближе к вероятности того, что объект есть в двух системах. Но количество сопоставлений при этом растет и чаще всего превышает прогноз. Это связано с тем, что с уменьшением числа атрибутов в составном ключе растет вероятность ошибочного сопоставления.
Проще говоря, с уменьшением количества атрибутов в составном ключе растет как число объектов сопоставленных правильно, так и число сопоставленных ошибочно. Как бы количество борется против качества. И в зависимости от бизнес-задачи можно выбрать стратегию матчинга, смещающую результат либо в сторону количества, либо в сторону качества.
А можно ли увеличить качество и количество одновременно? Конечно можно. Для этого нужно потратить больше, а иногда и намного больше ресурсов на дополнительную обработку данных.
«Дырки» в данных можно заполнять, получая их из других полей источника. Город локации можно получить из кода телефонного номера, ИНН, кода региона. Пол можно получить из имени и фамилии или по анализу авторского текста. Алгоритмов обогащения достаточно много.
Далее данные следует пропускать через фильтры. Фильтры могут быть как стандартные, так и специфические, связанные с особенностями наполнения и трансформации данных конкретного источника. Например, к стандартным можно отнести фильтр, убирающий непечатные символы, дубли, задвоения символов, скобки, кавычки, пробелы.
К специфичным фильтрам можно отнести обнаружение и замену символов другой языковой раскладки, которые выглядят одинаково визуально в обоих языках — например, буква О в английской раскладке в имени Оля. Или обнаружение и замену символов другой языковой раскладки, которые звучат одинаково или почти одинаково в обоих языках (Света и Sвета).
К нормализации можно отнести перевод на другой язык, транслитерацию, приведение к шаблону заполнения (название, марка, телефон, адрес, пол), а также замену коротких названий на полные, замену сленга и уменьшительно-ласкательных форм.
Даже при одном составе ключа для разных источников данных зачастую следует использовать разные критерии. Это связано с тем, как конкретный источник заполняется данными. Чтобы правильно подобрать критерии, желательно собрать и проанализировать статистику по заполнению полей источника. На улучшение качества может повлиять применение коэффициента частотности по полю в источнике (например, для марки машины, фамилии), коэффициента «емкости» (например, для названия населенного пункта в зависимости от того, насколько большой этот населенный пункт по количеству жителей).
При одновременном комбинированном использовании разных ключей матчинга можно применить коэффициенты в качестве условия использования того или иного ключа. Таким же образом можно задействовать и иные критерии, например, заполненность того или иного поля. Комбинировать матчинги по разным ключам между одними и теми же источниками можно и без применения условий — результат бывает вполне приемлемый.
Есть и другие алгоритмы матчинга, которые иногда кардинально отличаются от перечисленных выше. Например, матчинг по слабому ключу в условиях связи с другим объектом, уже проматченным по сильному ключу, если емкость такой связи по определению маленькая.
Приведем пример. У любой машины или квартиры за всю ее историю, в среднем, имеется от 1 до 5 владельцев. Если в двух системах объект квартиры или машины проматчен по сильному ключу, то субъекта — владельца этой квартиры, явно с ней связанного — можно матчить по любому самому слабому параметру, например фамилии и имени.
Объекты любой социальной сети или подобной ей структуры данных с большим числом устойчивых связей можно матчить по слабым ключам, принадлежащим не самому объекту матчинга, а его окружению. Сами объекты матчинга могут иметь в дополнение собственный слабый ключ, а могут не иметь. Фактически алгоритмизируется утверждение древнегреческого поэта Еврипида: «Скажи мне, кто твои друзья, и я скажу тебе, кто ты».
Для двух источников с одной или несколькими фотографиями объектов, которые явным образом связаны с их идентификаторами в источниках, можно применить матчинг по фотографиям. На фото выделяются объекты или лица и сравниваются с такими же объектами или лицами в другом источнике. По сути, по такому принципу работают нейросетевые сервисы типа «Is your portrait in a museum?» от Google: они матчат лицо с загруженной вами фотографии с лицами средневековых людей на портретах музеев. Критерий для матчинга специально выбран мягким, чтобы получалось отдаленное, но достаточное сходство.
При наличии большого числа авторской текстовой информации в разных источниках можно попробовать алгоритмы text mining, чтобы связать авторов. Это что-то вроде анализа почерка, только анализируется не форма написания, а содержание текста.
Чтобы повышать качество матчинга, требуется применять различные алгоритмы, которые в свою очередь требуют много ресурсов. Чем больше алгоритмов, тем больше ресурсов требуется. А если данных много, они постоянно изменяются, а считать их нужно быстро и недорого?
Скорее всего, хранить, обрабатывать и матчить данные традиционными способами не получится. Стоит подумать о bigdata-инфраструктуре. Таких решений сейчас уже довольно много, от разных вендоров и на любой кошелек.
В Сбербанке, например, матчинг внутрикорпоративных данных реализован как компонент data lake на Hadoop, Spark и HBase. Это решение позволяет обрабатывать разнородные неструктурированные данные большого объема, запускать вычисления на большом кластере, где хранятся данные без накладных расходов. При этом используется опенсорсный софт и commodity-сервера, что делает решение достаточно дешевым и эффективным для такого класса задач. Про Big Data на Hadoop написано много. Мне, например, вполне нравится, как это сделано у DataArt.
MatchBox — это система для автоматической нормализации и матчинга, которую мы используем в data lake Сбербанка. Она была недавно разработана в центре компетенций Big Data Сбертеха.
MatchBox в основном используется для построения и поддержания в актуальном состоянии единого семантического слоя данных и единого профиля клиента. Система дает возможность автоматически объединять информацию из большого числа источников в единую информационную суперсущность, встраиваться в процесс обновления информации источников. Это обогащает знания о текущих и потенциальных клиентах банка: их социально-демографических, психологических, поведенческих особенностях и потребительских предпочтениях.
MatchBox работает с данными любого качества, использует библиотеки с провалидированными алгоритмами нормализации и матчинга, имеет для этого конфигуратор пользовательских правил, работает в полностью автоматическом режиме по событию, расписанию или как сервис. MatchBox умеет масштабироваться, и количество регулярно обрабатываемых источников ограничивается только ресурсными квотами кластера.
Вот чего нам удалось добиться благодаря внедрению MatchBox:
Сейчас мы также исследуем и пилотируем сложные комбинаторные матчинги, графовые матчинги, матчинги по фото. А для источников, требующих высокой точности — подсистему валидации.
Я надеюсь, что статья поможет ответить на вопросы, связанные с матчингом, продвинуться в понимании собственных проблем работы с данными и найти подходы к их решению.
Начнем с бытового примера. У меня есть маленький сын. Недавно он освоил мобильный телефон и теперь любит таскать его с собой, чтобы, как взрослый, непринужденно позвонить кому-нибудь когда вздумается и поговорить на какую-нибудь «очень важную» тему. Звонит он только маме, папе и бабушке. Больше всего достается бабушке: порой он по 10 раз в день звонит ей, чтобы рассказать, что с ним произошло 5 минут назад.
В детском саду у него есть друг Денис, и у Дениса тоже есть мобильный телефон. Встретившись, они как взрослые меряются телефонами, но никогда не звонят друг другу. Я как-то спросил сына:
— Почему бы тебе не позвонить и не поболтать с другом о том о сем, обсудить свои дела?
— Папа, мне это совсем не нужно, мы и так встречаемся в саду каждый день и, если что, поговорим там. Дела подождут.
Мне стало интересно, как же так? Выяснилось, что просто ни он, ни Денис не знают своего собственного номера телефона и не могут ими обменяться. Налицо отсутствие связи из-за отсутствия ключей.
Что же такое матчинг?
Новые средства взаимодействия в обществе порождают новые возможности, более тесно связывают людей, а системам указывают об их связанности. Матчинг — это один из типов связанности, который указывает на отношения субъекта с самим собой. Например, когда на разных досках объявлений продается одна и та же машина, а мы хотим связать и воспринимать эти объявления вместе, как единое целое.
Зачем нужен матчинг?
Информация сегодня представляет ценность, которую можно монетизировать. Соответственно, дополнительная информация дает дополнительную ценность, увеличение прибыли или сокращение издержек — с помощью разработки новых фич, качественного изменения существующих или вообще создания новых продуктов.
Как правило, наш продукт четко связан с теми или иными объектами, знания по которым мы хотим обогащать. Чем больше дополнительной информации из новых источников мы получаем, тем актуальней становится задача объединения информации из всех источников в единое информационное пространство, как будто это атрибуты одной системы.
Трудности матчинга
Добыть и связать данные — вроде бы стандартная техническая задача. Но из-за ряда проблем это бывает затруднительно или вовсе невозможно:
- Нет общих ключей
Люди, организации, объекты – в каждой новой системе все регистрируются заново и получают новые собственные идентификаторы.
- Нет ключей вообще
Для некоторых типов данных ID присваивается отдельным событиям или сообщениям в потоке, а не тому объекту, который нас интересует. Например, система фиксирует кредитные заявки, и если один и тот же человек оформит две отдельные заявки, то это будет два разных ID. А для самого человека ID в системе не будет.
- Записи по ключу не уникальны
В идеале каждому уникальному ID соответствует уникальный объект, но на практике это бывает не так. Например, машина сменила цвет или номер ПТС, человек сменил фамилию или пол. По формальным признакам для автоматической системы это новый объект. Также проблема может возникнуть если, например, оператор вместо поиска уже существующей записи в базе просто заводит новую — так ему проще.
- Записи по ключу ошибочны или преднамеренно испорчены
Например в социальных сетях, где владелец странички искажает свое имя и фамилию или совсем заменяет их на вымышленные. Можно найти десятки Иванов Ургантов или Владимиров Познеров, и это не однофамильцы.
- Записи по ключу непостоянны
В разное время для одного и того же ID можно ожидать разные объекты или субъекты. Например, когда у телефонных номеров меняются владельцы.
Получается, что связать объекты двух систем между собой по ключу бывает либо невозможно, либо процент и качество связанности оказываются ниже желаемого уровня. Можно попробовать собрать ключ как комбинацию нескольких информационных полей, составной ключ. Но здесь возникают новые трудности:
- Поля составного ключа недостаточно заполнены
Никто не обещает, что обычные информационные поля будут «not null». А дальше как повезет. Чем больше полей в составном ключе, тем больше вероятность, что какие-то ключи не будут получаться.
- У полей в составном ключе разные стандарты заполнения
Например, адрес офиса организации заполняется произвольным образом: д.5 к.2 офис 16; дом 5 корпус 2 офис 16; 5-2-16. Или телефон: +7(495)344-3…, 8-495-344…, 495344….
Кроме того, для информационных полей в составном ключе характерны трудности, которые мы упоминали ранее. Поля, входящие в составной ключ, тоже могут быть не уникальны, ошибочны, преднамеренно искажены и не постоянны.
Количество vs качество
Как же победить перечисленные выше трудности и добиться 100% матчинга? Начать стоит с вопроса: а действительно ли нужно достигать таких высоких уровней качества? Может, для решения бизнес-задачи вполне достаточно 70%?
Есть у нас составной ключ, состоящий из набора атрибутов. Каждый из них с некоторой вероятностью будет заполнен и с некоторой вероятностью подойдет для применения в качестве элемента ключа. Вероятность что весь составной ключ будет нормален — это произведение всех вероятностей по всем атрибутам ключа. Все это еще нужно умножить на вероятность того, что объект в принципе присутствует в двух системах. Тогда мы получим вероятность матчинга. А умножив ее на общее число сущностей, получим количественный прогноз по сопоставлению.
Чем меньше атрибутов в составном ключе, тем вероятность матчинга выше и при этом ближе к вероятности того, что объект есть в двух системах. Но количество сопоставлений при этом растет и чаще всего превышает прогноз. Это связано с тем, что с уменьшением числа атрибутов в составном ключе растет вероятность ошибочного сопоставления.
Проще говоря, с уменьшением количества атрибутов в составном ключе растет как число объектов сопоставленных правильно, так и число сопоставленных ошибочно. Как бы количество борется против качества. И в зависимости от бизнес-задачи можно выбрать стратегию матчинга, смещающую результат либо в сторону количества, либо в сторону качества.
Обогащение, фильтрация, нормализация
А можно ли увеличить качество и количество одновременно? Конечно можно. Для этого нужно потратить больше, а иногда и намного больше ресурсов на дополнительную обработку данных.
«Дырки» в данных можно заполнять, получая их из других полей источника. Город локации можно получить из кода телефонного номера, ИНН, кода региона. Пол можно получить из имени и фамилии или по анализу авторского текста. Алгоритмов обогащения достаточно много.
Далее данные следует пропускать через фильтры. Фильтры могут быть как стандартные, так и специфические, связанные с особенностями наполнения и трансформации данных конкретного источника. Например, к стандартным можно отнести фильтр, убирающий непечатные символы, дубли, задвоения символов, скобки, кавычки, пробелы.
К специфичным фильтрам можно отнести обнаружение и замену символов другой языковой раскладки, которые выглядят одинаково визуально в обоих языках — например, буква О в английской раскладке в имени Оля. Или обнаружение и замену символов другой языковой раскладки, которые звучат одинаково или почти одинаково в обоих языках (Света и Sвета).
К нормализации можно отнести перевод на другой язык, транслитерацию, приведение к шаблону заполнения (название, марка, телефон, адрес, пол), а также замену коротких названий на полные, замену сленга и уменьшительно-ласкательных форм.
Даже при одном составе ключа для разных источников данных зачастую следует использовать разные критерии. Это связано с тем, как конкретный источник заполняется данными. Чтобы правильно подобрать критерии, желательно собрать и проанализировать статистику по заполнению полей источника. На улучшение качества может повлиять применение коэффициента частотности по полю в источнике (например, для марки машины, фамилии), коэффициента «емкости» (например, для названия населенного пункта в зависимости от того, насколько большой этот населенный пункт по количеству жителей).
При одновременном комбинированном использовании разных ключей матчинга можно применить коэффициенты в качестве условия использования того или иного ключа. Таким же образом можно задействовать и иные критерии, например, заполненность того или иного поля. Комбинировать матчинги по разным ключам между одними и теми же источниками можно и без применения условий — результат бывает вполне приемлемый.
Другие матчинги
Есть и другие алгоритмы матчинга, которые иногда кардинально отличаются от перечисленных выше. Например, матчинг по слабому ключу в условиях связи с другим объектом, уже проматченным по сильному ключу, если емкость такой связи по определению маленькая.
Приведем пример. У любой машины или квартиры за всю ее историю, в среднем, имеется от 1 до 5 владельцев. Если в двух системах объект квартиры или машины проматчен по сильному ключу, то субъекта — владельца этой квартиры, явно с ней связанного — можно матчить по любому самому слабому параметру, например фамилии и имени.
Объекты любой социальной сети или подобной ей структуры данных с большим числом устойчивых связей можно матчить по слабым ключам, принадлежащим не самому объекту матчинга, а его окружению. Сами объекты матчинга могут иметь в дополнение собственный слабый ключ, а могут не иметь. Фактически алгоритмизируется утверждение древнегреческого поэта Еврипида: «Скажи мне, кто твои друзья, и я скажу тебе, кто ты».
Для двух источников с одной или несколькими фотографиями объектов, которые явным образом связаны с их идентификаторами в источниках, можно применить матчинг по фотографиям. На фото выделяются объекты или лица и сравниваются с такими же объектами или лицами в другом источнике. По сути, по такому принципу работают нейросетевые сервисы типа «Is your portrait in a museum?» от Google: они матчат лицо с загруженной вами фотографии с лицами средневековых людей на портретах музеев. Критерий для матчинга специально выбран мягким, чтобы получалось отдаленное, но достаточное сходство.
При наличии большого числа авторской текстовой информации в разных источниках можно попробовать алгоритмы text mining, чтобы связать авторов. Это что-то вроде анализа почерка, только анализируется не форма написания, а содержание текста.
Big data
Чтобы повышать качество матчинга, требуется применять различные алгоритмы, которые в свою очередь требуют много ресурсов. Чем больше алгоритмов, тем больше ресурсов требуется. А если данных много, они постоянно изменяются, а считать их нужно быстро и недорого?
Скорее всего, хранить, обрабатывать и матчить данные традиционными способами не получится. Стоит подумать о bigdata-инфраструктуре. Таких решений сейчас уже довольно много, от разных вендоров и на любой кошелек.
В Сбербанке, например, матчинг внутрикорпоративных данных реализован как компонент data lake на Hadoop, Spark и HBase. Это решение позволяет обрабатывать разнородные неструктурированные данные большого объема, запускать вычисления на большом кластере, где хранятся данные без накладных расходов. При этом используется опенсорсный софт и commodity-сервера, что делает решение достаточно дешевым и эффективным для такого класса задач. Про Big Data на Hadoop написано много. Мне, например, вполне нравится, как это сделано у DataArt.
Наш MatchBox
MatchBox — это система для автоматической нормализации и матчинга, которую мы используем в data lake Сбербанка. Она была недавно разработана в центре компетенций Big Data Сбертеха.
MatchBox в основном используется для построения и поддержания в актуальном состоянии единого семантического слоя данных и единого профиля клиента. Система дает возможность автоматически объединять информацию из большого числа источников в единую информационную суперсущность, встраиваться в процесс обновления информации источников. Это обогащает знания о текущих и потенциальных клиентах банка: их социально-демографических, психологических, поведенческих особенностях и потребительских предпочтениях.
MatchBox работает с данными любого качества, использует библиотеки с провалидированными алгоритмами нормализации и матчинга, имеет для этого конфигуратор пользовательских правил, работает в полностью автоматическом режиме по событию, расписанию или как сервис. MatchBox умеет масштабироваться, и количество регулярно обрабатываемых источников ограничивается только ресурсными квотами кластера.
Вот чего нам удалось добиться благодаря внедрению MatchBox:
- высокая скорость обработки больших объемов при низкой себестоимости процесса
- объединение большого числа источников
- полная автоматизация матчинга на bigdata-кластере — и, как следствие, низкая стоимость
- регулярность матчинга — при использовании в регулярных циклических бизнес-процессах финансовые издержки снижаются
- высокое качество матчинга за счет нормализации, обогащения и подбора оптимальной конфигурации — стоимость конечных данных повышается
- вариативность матчинга благодаря конфигурированию правил — стоимость внедрения новых инициатив снижается
- унификация публикуемого результата (низкой стоимости внедрения новых инициатив)
- выстраивание цепочек матчинга
Сейчас мы также исследуем и пилотируем сложные комбинаторные матчинги, графовые матчинги, матчинги по фото. А для источников, требующих высокой точности — подсистему валидации.
Я надеюсь, что статья поможет ответить на вопросы, связанные с матчингом, продвинуться в понимании собственных проблем работы с данными и найти подходы к их решению.
Комментарии (7)
leliksss Автор
16.05.2018 15:19В ленте российского Фейсбука почти в каждом крупном посту в комментариях обязательно есть хотя бы один Украинец, который пишет Роисся, Ватники и подобное вне зависимости от содержания поста. Можно разметить выделить в кластер таких людей просто по одним и тем же используемым словам или фразам.
drema
16.05.2018 16:02Матчинг говорите есть, ну-ну. На меня заводили две зарплатные карты, вторая была заведена с другими паспортными данными, потому как поменялся паспорт. Два раза приходил в отделение банка и писал заявление об изменении паспортных данных и объединении учетных записей, мобильный то у меня один и он привязан к старой карте.
Ничего так и не было сделано.Areso
16.05.2018 17:06Угу. У меня также с зарплатной картой начудили.
Но я правда от нее отказался, так что не знаю, слили они профили успешно с зарплатным, или нет…
Rupper
17.05.2018 06:55Девиз сбертеха «для умного человека нет таких проблем, создав себе которые, он не мог бы решить!»
Areso
Шел 2018 год:
«вот где карту вам открывали, туда и идите. У них есть поиск по ФИО, а у нас нет, а по паспорту вашему у вас других карт нет, и нет, наличие другой карточки нашего банка у вас на руках ничего не значит для нас»(с) единого профиля клиента, говорите? Повезло, что нашли очепятку (там было два места в которых часто ошибаются, ИЧХ, в одном из них и ошиблись) и сделали-таки слияние двух профилей.
Sablast
добавлю. если карты выпущены в двух разных регионах, то у вас появляется два личных кабинета. Из обоих кабинетов видны все карты, но реквизиты карты можно посмотреть только из того кабинета которому эта карта принадлежит.
RootHub
На самом деле, это не так, есть две карты открытых в свердловской области, и одна в Санкт-Петербурге, один так же личный кабинет и использую, который был еще получен в свердловской области.