Общий стандарт отчетности (CRS), выпущенный ОЭСР, требует, чтобы подотчетные финансовые учреждения (FI) получали идентификационный номер налогоплательщика (TIN) определенных клиентов. Это ставит перед финансовыми учреждениями ряд практических проблем. Основные проблемы, вызывающие озабоченность, связаны с подтверждением полученных ИНН и действиями с клиентами, которые утверждают, что не могут предоставить ИНН. К сожалению, регуляторы не рассматривают эту тему подробно. Таким образом, подотчетные финансовые организации должны учитывать не только нормативные требования, но также операционные и стратегические аспекты при разработке политик и внедрении необходимых процессов.
Как правило, в соответствии с CRS Reporting FI должны получить TIN всех владельцев счетов и контролирующих лиц, которые являются резидентами подотчетной юрисдикции. Тем не менее, в некоторых юрисдикциях (например, в Германии и Сингапуре) объем сбора TIN был расширен при внедрении CRS на местном уровне и требуется, чтобы все иностранные клиенты самостоятельно подтверждали наличие TIN независимо от налогового резидентства. Для Сингапура это обязательство распространяется даже на местных клиентов. Аналогичным образом, некоторые финансовые организации могут принять решение о получении TIN от всех клиентов, а не только от тех, которые являются резидентами подотчетной юрисдикции, в рамках более широкого подхода или в ожидании того, что юрисдикции станут подотчетными позднее.
Ограниченные исключения из требования о получении TIN предусмотрены CRS. Во-первых, когда юрисдикция налогового резидентства клиента не выдает ИНН своим резидентам. Во-вторых, когда внутреннее законодательство юрисдикции налогового резидентства клиента не требует получения ИНН. Несмотря на то, что это прямо не упоминается в CRS, существует больше ситуаций, когда клиент не может предоставить TIN. Например, хотя большинство юрисдикций обычно выдают ИНН, они могут не делать этого для определенных групп жителей (например, несовершеннолетних). Кроме того, новые жители могут еще не получить свой ИНН, когда его просят предоставить.
Если клиент не может предоставить ИНН, подотчетные ФО должны попросить клиента аргументированно объяснить этот факт и, в зависимости от объяснения, получить ИНН позднее. Для большинства юрисдикций, приверженных внедрению CRS, на портале ОЭСР указано, выдают ли они обычно ИНН, которые могут использоваться отчитывающимися финансовыми учреждениями для подтверждения обоснованности таких пояснений. К сожалению, руководство на Портале ОЭСР не затрагивает ситуации, когда определенным группам резидентов не присвоен ИНН. Аналогичным образом, если сбор ИНН распространяется на всех иностранных резидентов (например, как в Германии или Сингапуре), портала ОЭСР будет недостаточно, поскольку на нем отсутствует информация о неучаствующих юрисдикциях. В таких ситуациях отчитывающимся финансовым организациям необходимо решить, использовать ли другие источники и провести необходимые исследования. В качестве альтернативы они могут принять решение не выходить за рамки информации на портале ОЭСР и доверять заявлению клиентов.
Еще один интересный вопрос заключается в том, должен ли, и если да, то каким образом, после получения ИНН подтверждаться подотчетным финансовым учреждением. В часто задаваемых вопросах OECD CRS четко указано, что отчитывающиеся финансовые организации не обязаны «подтверждать формат и другие характеристики ИНН», предоставляемого клиентом. Тем не менее, отчитывающиеся финансовые организации обязаны проводить «проверку на обоснованность» всех получаемых ими самосертификаций. Подотчетным финансовым организациям не разрешается полагаться на самостоятельную сертификацию, если они знают или имеют основания знать, что самосертификация неверна или ненадежна, и в этом случае разумно предусмотрительный человек усомнится в сделанном заявлении. Возможно, если клиент указывает, что его ИНН, например, «123456» или «abcdef», у подотчетного финансового учреждения есть основания знать, что самосертификация неверна. Таким образом, необходимо выполнить базовую проверку.
Тем не менее, подотчетные финансовые организации могут пойти дальше и подтвердить формат полученных TIN. Подотчетные лица будут быть сообщены, независимо от того, есть ли ИНН в файле, это помогает повысить качество передаваемых данных и может предотвратить последующие административные усилия, когда принимающие юрисдикции возвращаются с вопросами о конкретных клиентах, для которых был сообщен неверный ИНН. Кроме того, внедрение процессов проверки ИНН теперь предотвращает обременительные меры по исправлению положения, если нормативные требования будут ужесточены в будущем. Наконец, обеспечение правильности информации в файле обычно также является общим требованием законов о защите данных. Например, Швейцария предписывает это в статье 5 Федерального закона о защите данных (Bundesgesetz über den Datenschutz).
Для отчитывающихся финансовых организаций, решивших применить эти дополнительные усилия и подтвердить формат TIN, портал ОЭСР, вероятно, является первым ресурсом, который следует рассмотреть. Однако информация о ИНН отсутствует не только для некоторых юрисдикций, но и там, где она доступна, она имеет разное качество и неоднородно структурирована. Таким образом, отчитывающимся финансовым организациям может потребоваться перевести информацию с портала ОЭСР в более полный формат, чтобы ее могли использовать операционные группы или в качестве входных данных для их ИТ-систем.
Более того, даже для юрисдикций, которые предоставляют подробную информацию о TIN, проверка может создать дополнительные проблемы. Например, если в юрисдикции используются разные идентификационные номера, а клиент не знает, какой номер считается ИНН для целей CRS, могут потребоваться обременительные последующие обсуждения и дополнительные инструкции.
Хотя некоторые базовые «тесты на обоснованность» являются обязательными, всестороннего требования или решения для проверки ИНН не существует. Таким образом, в настоящее время проверка может выполняться только на основе «максимальных усилий», и подотчетные финансовые организации должны тщательно взвешивать потенциальные преимущества и проблемы при принятии решения о том, как решить этот компонент CRS.