|
|
| Frequently Asked Questions |
|
Reporting Requirements
A Suspicious Transaction Report (STR) is a report that is submitted when a bank (or other obligated reporting entity) has reason to suspect that funds are the proceeds of an offense (illicit proceeds) or related to the financing of terrorism.
A Cash Transaction Report (CTR) is a report that is submitted when a bank (or other obligated reporting entity) completes a transaction, or a series of linked transactions for a customer or an account that take place within a single day and that involve more than $10,000 USD (40 million Riels) or its equivalent in other currency.
Suspicion can have many definitions. For purposes of reporting, suspicion is created when the transaction activity or the behavior of a customer does not match our expectations based on the customer's profile, or when the transaction activity or behavior of a customer matches what we know about criminal offenses and their proceeds. This suspicion persists even after further examination and investigation.
If you are one of the entities described in Article 1 of the Prakas on Anti-Money Laundering and Combatting the Financing of Terrorism and you or your institution have been party to a transaction or an attempted transaction that meets the criteria specified therein, then you need to submit a report to CAFIU.
You need to report all the data that you have available to you regarding the transaction in accordance with the CTR or STR specification, respectively.
The Anti-Money Laundering Law and Prakas requires specific Customer Due Diligence measures, including customer identification, to be performed prior to establishing a business relationship and prior to executing a one-off transaction exceeding the threshold and whenever there is a suspicion of money laundering or terrorist financing and whenever doubt exists regarding the veracity of information provided. Therefore, you should update your processes and your records so that the required information is in your possession.
There may be cases where the required information does not exist. For example, it is possible that a building number for an address does not exist. In such cases you may enter “N/A”. Note: there is a distinction between information that you don’t have and information that does not exist. If the required information exists, then you must obtain it and report it (see above).
Suspicious transaction reports must be submitted to CAFIU within 24 hours of detection.
Cash transaction reports must be submitted to CAFIU no more than 14 days after completion of the transaction(s).
Reports are required both by the AML law and by the AML Prakas which, in turn, reflect international standards. Failure to file reports in accordance with the Law and the Prakas may result in administrative sanctions including limits on allowable transactions, demotion of officials or directors at the reporting entity, fines, and revocation of business licenses or penal sanctions including fines and imprisionment.
Yes, all owners should be listed.
Yes, all owners should be listed.
Anybody with “signature authority” over the account, including the initiators of the account and anyone who is able to direct the disposition of account assets and authorize and conduct transactions, should be listed as an individual account owner. If a legal entity is listed as an account owner, then that information should also be provided.
Electronic Reporting System
Reports must be submitted in electronic format and must adhere to the appropriate specification. You are free to use whatever means at your disposal to create documents in the proper electronic format.
No, according to the Guideline you may transmit the report through manual means. However such transmission is strongly discouraged. See the guideline for instructions.
OpenPGP is the most widely used email encryption standard in the world using public key cryptography. The OpenPGP protocol defines standard formats for encrypted messages, signatures, and certificates for exchanging public keys.
OpenPGP is a standards-based open version of the Pretty Good Privacy (PGP) specification for secure data communications using various forms of encryption
See one of the following for a complete description:
• http://www.openpgp.org/
• http://en.wikipedia.org/wiki/Pretty_Good_Privacy
PGP, as an open specification, along with its implementations is widely used and has been closely scrutinized by professional cryptographers in academia, government, and commercial sectors. To the best of publicly available information, there is no known method which will allow a person or group to break PGP encryption by cryptographic or computational means
Public-key cryptography refers to a cryptographic system requiring two separate keys, one of which is secret and one of which is public. Although different, the two parts of the key pair are mathematically linked. One key locks or encrypts the plaintext, and the other unlocks or decrypts the cipher text. Neither key can perform both functions by itself. The public key may be published without compromising security, while the private key must not be revealed to anyone not authorized to read the messages.
The Reporting Entity ID is used by CAFIU to uniquely identify reporting entities. It is assigned by CAFIU and is found on your Electronic Communication Agreement.
No. The electronic form is provided as a convenience only. You are free to use any available means to create your report in the proper electronic format. CAFIU encourages you to create the form through a direct extract from your core banking system where that is technically and economically feasible.
Yes,the electronic forms provided were designed for use with InfoPath only.
Yes, the InfoPath forms are not locked and you are encouraged to modify them in any way that improves your ability to create and transmit accurate and timely reports. Keep in mind, however, that the data sources for the forms are their respective XML Schema files (.xsd). If you modify the data source in any way then the submitted XML files will no longer be valid and will be rejected.
You are encouraged to provide copies to CAFIU of any modifications that you have made that might be of use to the reporting community as a whole.
InfoPath 2007 has a “Merge Forms” feature. Using this feature one can create a template form with all of the fixed (participant information, account information) information for a transaction that repeats frequently. The template can then be merged into the report and information particular to the transaction (e.g. transaction amount, date, type) can be added. This will save the trouble and potential errors associated with repeated manual data entry.
You must use Microsoft Office InfoPath 2003, Service Pack 2 or later.
InfoPath is included in:
• MS Office 2003 Professional and Professional Enterprise Editions
• MS Office 2007 Ultimate, Professional Plus, and Enterprise Editions. Additionally it is available as a separate license.
• MS Office 2010 Professional Plus
[ stay tuned … to be determined]
You must immediately stop using it and repeat the electronic information exchange agreement process.
If you feel your key has been compromised, then see above.
Yes, this is technically possible. However there are some practical problems with this approach. The first is that each branch would need to ensure that it is sending a unique file name so the sequence numbers would need to be coordinated. Encryption keys would need to be geographically shared which may cause security issues. You would need to find a way to match receipts with submissions to ensure all reports were actually received and validated by CAFIU.
More importantly, however, when the reporting entity lacks a centralized and concurrent database it may be difficult to detect patterns of money laundering, such as structuring of transactions to avoid reporting thresholds.
CAFIU shall endeavor to process report submissions and issue receipts within one hour of receiving valid reports.
Yes, each file will be validated as a separate process resulting in the generation and transmission of a receipt.
Reporting System Software
Gpg4win is free OpenPGP-compatible software which you can find and download from its official website: http://www.gpg4win.org
For convenience, a copy is also on the CAFIU website download page.
Below are some of e-mail clients supported by OpenPGP software:
• Microsoft Outlook 2007 (Recommended by CAFIU Electronic Reporting System)
• Mozilla Thunderbird
• Microsoft Windows Live Mail
• Lotus Notes
• Novell GroupWise6.5.3
The combinations of e-mail clients and OpenPGP-compatible plug-ins known to works are as followings:
• Microsoft Outlook 2007 and GpgOL (Gpg4win plugin in Microsoft Outlook)
• Microsoft Outlook 2007 and Symantec PGP Desktop
• Mozilla Thunderbird and Enigmail (Plugin of OpenPGP message encryption and authentication for Thunderbird)
Yes, you are free to use any e-mail client whether it is commercial, open source, or a client of your own creation so long as the message is encrypted and transmitted in accordance with the Guideline.
Yes, keeping in mind that you are responsible for protecting your private key.
E-mail servers, like all servers, have availability characteristics. Commercial providers generally have good availability characteristics that are functions of service level agreements. It is your responsibility to choose service providers and service level agreements, or to create your own service, such that availability is not a serious or chronic issue. NBC will take measures to ensure that its e-mail servers have adequate availability.
Developing Your Own Reporting System
Each bank's "core system" is different. For that reason, CAFIU cannot provide advice or technical assistance in this area. However, XML is a widely used business-to-business format and extensive documentation on its use is freely available. Automated tool support is also widely available. Extracting a report in XML format should be programmatically similar to extracting a report in any other format.
The CAFIU STR/CTR specifications require only those data that are of analytic value and that are required by law for KYC and record-keeping purposes. Much of the analytic value is derived from the ability to match reporting data with data already held in CAFIU databases as well as with data held in external databases. For this matching to be effective and efficient it has to occur on a field-by-field basis with each field representing a distinct common piece of information. For example, when matching a name, the surname needs to be matched with the surname and the given name with the given name. Some core systems may store this information in an aggregate field where each piece of information is not distinct. For example, the core banking system may store all components of a name or of an address in as single field. In some cases CAFIU has made a temporary accommodation by creating an aggregate field in the reporting specification. In other cases, such as a name, the value of an identifier is so critical that this cannot be done. In such a case the reporting entity has at least three choices: 1) it can modify its core system; 2) it can create a separate Customer Information File (CIF) with data broken out into separate fields; 3) it can manually enter data into the electronic form.
Address Fields: The following fields are defined in the XML Schema Documents and may be used: AddressTemp1, AddressTemp2, AddressTemp3.
FirstName_Khmer, LastName_Khmer: You may enter “N/A”.
IssueDate (for identification documents): Enter 1 January 1950 .
You may be able to. But this depends primarily upon all the required data being available in the source document. If it is then you may be able to apply an XSL style sheet, or an XML map, or you may be able to write a custom report that conforms to the specification. You can find many examples on the internet. CAFIU will not be able to provide assistance.
There is no such thing as 100% security in any system and in any place. However, secure e-mail is different from ordinary e-mail. It implements all fundamental features of transactional security including authentication, integrity, privacy, and non-repudiation. OpenPGP is widely used and has been thoroughly examined over many years by multiple communities, including top security professionals and governments. There is no known method by which an individual or organization of any type can break PGP encryption by cryptographic or computational means. Weaknesses are exponentially more likely to be related to local security practices (e.g. choice of password and protection of private keys). If you are still not convinced, you are free to use the hand delivery method for transmitting reports. However, keep in mind that hand delivery introduces its own set of security issues.
PGP and OpenPGP are compatible at a protocol level. Any commercial product that correctly implements PGP should be compatible with OpenPGP. Therefore, you are free to use any product that accurately implements that specification, including commercial products
A Java program has been provided, with source code, in the “Software” section of this website. A program compiled for a Windows environment is also referenced in the same section. If these don’t meet your specific purposes, most major programming environments contain tools and libraries for validating XML programs against schema. You can use these tools and libraries to write your own validation programs.
Yes, you can use InfoPath for that purpose. However large files can become very slow to load and very slow to validate.
|
|