Can an Utility work for Know Your Customer (KYC) Requirements? David Gustin - March 23, 2015 5:15 AM | Categories: Trade Credit Commentary | Tags: KYC Registry, SWIFT SWIFT had developed a KYC Registry for correspondent banking. The KYC Registry platform is operational with banks contributing their data. The goal of the utility is to enables banks to share and access the standardized set of qualified data and documentation needed to fulfil correspondent banking KYC obligations and customer due diligence requirements. Registry users will retain ownership of their KYC information, along with control over who can access it via the secure online platform. I spoke to one global expert who has designed and developed payment infrastructure to get his views on the KYC Registry. Maksim Rokhline is a digital payments and commerce expert and has developed payment products across many geographies and is a principal consultant for Amalgam payment. Maksim sees some definite concerns with the current SWIFT KYC registry: Limited to correspondent banking only. One (a bank) can only pull a KYC level info about another financial institution. One (a bank) cannot request information regarding an enterprise account holder of another bank in the registry network. So, SWIFT KYC solution addresses a core requirement for one bank to know another. If I (a non bank) manage a credit facility to provide early payments to a chain of suppliers, I don’t knock on the door of this utility. I will have to obtain and adjudicate the (suppliers) info somehow else. Not real-time AND actually quite manual. As a bank analyst I manually request a piece of data about another FI and then wait. It takes an analyst of that FI to check a request queue in his SWIFT dashboard, make a decision as to whether to share the info or not and then respond with an approval. That might take a while. Ideally, you would want a certain event – supplier early pay application, for instance – to be a trigger for a data request, and immediately, based on other banks policies and settings, an auto respond-authorization will follow. So, what did Maksim feel is good about SWIFT KYC registry? Run by a reputable Network Owned by banks. Responsibility and liability are with the banks! Ongoing character of information shared. Constantly updated Unified protocol and data specifications Structure rules ‘of engagement’ among members Simple workflow If I were to design it I would create an authentication, authorization and settlement mechanism for ‘documents’ movement. Open to all use cases (of KYC requirements compliance. ) – be it a credit application, merchant acquiring or correspondent banking. It would be managed by a network, owned by banks and exposed to all ‘certified’ developers and applications (say, PrimeRevenue’s platform can make a request to a network to obtain KYC information and a “bank-information manager” would respond through a network with an approval (or a decline). A network would facilitate ‘some sort of settlement’ of requested (and approved) information. It should be a Network play, like Visa, Mastercard or Swift. It is rightfully an oligopoly framework due to (1) economies of scale, (2) reputation as a barrier as highly sensitive info is shared and (3) other barriers – Government and strategic. It should support both Pull and Push mechanisms of data interchange Maksim makes great points. My personal opinion is that if you are a bank (or vendor) and outsource the due diligence process – particularly onboarding of the relationship, you are not making value judgments about risk but you are about the adequacy of the KYC information, and that is a process that should be owned by banks, not some outsourced provider. What do others think? p.s. to sign up for TFMs weekly digest, register here Related Articles Onboarding – It’s all about the Front, Middle and Back… Supplier Onboarding – Dont shortshift Execution Part I Discuss this: Cancel reply Your email address will not be published. Required fields are marked *Comment Name * Email * Website Notify me of new posts by email.