General Requirements – CRS/FATCA One

This table contains all functional and non-functional requirements and how TransWorld Compliance complies with them, based on the official evaluation form.

REQUIREMENTS	COMPLIES	COMMENTS (IF APPLICABLE)
FUNCTIONAL REQUIREMENTS
Initially, the system must allow the loading of data to the application by means of an Excel file. At a later stage, extract data from the DWH source of the applicable systems (CRM, Core Banking, SIB, among others). Banking, SIB, among others).	YES	The system allows data upload via Excel file, XML or API connector (web services).
Enable data homologation	YES	All data adheres to the DGI's specifications.
The minimum required fields are: a. For natural persons. ✓ Name of individuals (First name, middle name, last name) ✓ Date of birth. ✓ Address ✓ City (Address) ✓ Country (Address) ✓ Nationality ✓ TIN ✓ Country issuing the TIN.	YES	TWC's CRS/FATCA One supports all the required fields.
b. For legal entities. ✓ Name of entity ✓ City (Address) ✓ Country (Address) ✓ TIN ✓ Country issuing the TIN ✓ Data of the persons, who exercise control over the accounts (applies to legal entities) ✓ Data of the persons, who exercise control of the accounts (applies to legal entities) legal entities) - First name, middle name, last name - City (Address) - Country (Address) - TIN - Country issuing the TIN	YES	TWC's CRS/FATCA One supports all the required fields.
c. For all types of passive accounts: ✓ Account number. ✓ Date account opened. ✓ Type of account ✓ Type of account currency. ✓ Balance as of December 31 ✓ Account status as of December 31 (active, inactive, closed, garnished, etc). ✓ Type of payment (interest, for example). ✓ Currency of Payment Type.	YES	TWC's CRS/FATCA One supports all the required fields.
4. It should allow the uploading of monthly records in order to identify possible inconsistencies. Currently they are reported: a. Banco: 300 accounts for CRS and 13 for FATCA, which may increase over time. b. Capital: 16 accounts for CRS and 1 for FATCA, which may increase over time.	YES	The software allows the loading of records in the desired periodicity. Number of reported accounts already considered in the commercial proposal submitted. Multiple reporting financial institutions (e.g. a bank and an investment firm) is supported with the option of firewalling data or sharing data.
5. It must allow to manage a rule base that applies with the CRS and FATCA parameters of the DGI of Panama to the uploaded data to identify reportable clients, indications and minor deficiencies.	YES	We currently have clients (financial institutions) in Panama that report CRS and FATCA according to the parameters of the DGI of Panama. CRS/FATCA One raises red and yellow flags to identify any data deficiencies or indica.
6. The system must generate the XML schema required by the tax authority, in this case the General Revenue Directorate (DGI). The supplier must be in charge of keeping the XML versions updated for FATCA and CRS (with an exclusive report creation engine for CRS/FATCA of Panama).	YES	The system generates XML required by the AF of Panama (DGI), whose versions are always updated.
7. Allow validation of the TIN formats according to the country generating the TIN.	YES	The system validates that the TIN format matches the issuing country. Flags are raised for invalid TIN formats.
8. Must allow by means of intelligent and jurisdiction-specific rule bases a full discovery of the customer base to reveal hidden indicia, data deficiencies (e.g. invalid TIN format) and changes in circumstances in order to have a true status of the customer base with respect to FATCA and CRS.	YES	The system provides jurisdiction-specific and up-to-date rule bases for both FATCA and CRS. The entity can configure their Rule Bases with a wide number of customizable parmeters.
9. It must contain a case/inconsistency/findings/indictment management module that uses flags to intelligently classify flags to intelligently classify clients to allow knowing the status of CRS and/or FATCA data. a. Red flag: Reportable customer with indications. b. Green flag: Reportable customer with no indications. c. Yellow flag: Reportable client with minor deficiencies	YES	The system has 4 types of warning flags: red, for major inconsistencies; yellow, for minor inconsistencies; green with white check, for correct reportable records; green with white G, for correct non-reportable records.
10. It should allow users to add supporting documents (ID, self-certificates, W8, W9, etc.), as well as expiration dates if necessary as evidence of review.	YES	It allows the addition of supporting documents and comments, generating an activity log.
11. It should allow with a single click to generate the reports in XML for CRS and FATCA according to the regulation, jurisdiction and the year to report.	YES	Data is staged, available for final approval, and then submission for the final XML which is submitted to the DGI.
12. It should allow to validate that the reports have the correct format before being sent.	YES	The system has a validation step before obtaining the report.
13. It should allow to provide proof of evidence to regulators of the submission of reports.	YES	The system allows the generation of digital evidence for the bank's own records or for submission to regulatory bodies.
14. Must have a repository of all information for FATCA and CRS, year after year.	YES	The system allows access to information from previous years and keeps permenant records of all previously submitted data.
15. The system should identify changes of circumstances in the data of its clients and leave an audit trail with different types of reports. audit trail with different types of reports.	YES	All data changes are recorded in a permanent audit log.
16. The tool must allow invalidating or amending reports previously sent to the tax authority DGI in the required XML format. DGI tax authority in the required XML formats.	YES	Void, Amend, Correct, and new submissions are allowed under FATCA, Void, Correct, and new submissions are allowed under CRS. CRS/FATCA One handles tracking of all MessageRefIDs, DocRefIDs, CorrMessageRefIDs, and CorDocRegIDs automatically.
INFORMATION FLOW
1. Load data: (a) Using the Excel file or making connection with the data source in an automated way through web services integrating it to CRM, Core Banking, SIB, among others (in accordance with the phases indicated above)."	YES	CRS/FATCA One will load data already extracted from core systems and makes available a Web Services API for programmic connectivity between core systems and CRS/FATCA one.
2. Classification and Remediation a) Once the data is uploaded, the cross validation rule base is applied to it, which should intelligently classify your customer data for both FATCA and CRS. In this way, the system is going to identify red flags, major and minor deficiencies according to local legislation for both FATCA and CRS.	YES	Red, Yellow, and Green flags are raised. Red flags are raised for major deficiencies/indicia, yellow flags for minor difficiencies, and green menas we have the data needed and the record is either reportable or not reportable.
b) The system will compare the data entered against the rule bases (which encapsulate the parameters of each regulation defined by the DGI tax authority each year) to subsequently raise flags that indicate indications, errors, lack of information. These flags are alerts that will allow to verify the database in order to determine the clients that are subject to report FATCA and CRS (adjusting to the requirements requested by the DGI tax authority).	YES	Red, Yellow, and Green flags are raised. Red flags are raised for major deficiencies/indicia, yellow flags for minor difficiencies, and green menas we have the data needed and the record is either reportable or not reportable.
c) Within this case management tool it will allow us to upload support files (passports, forms, self-certificates, among others) and validate the TIN format, generate audit reports, view existing relationships between legal and natural clients, among others.	YES	Supporting document can be uploaded, stored, and searched.
d) It will also serve as a repository of information for FATCA and CRS, which must be encrypted and have a backup for any contingency.	YES	TWC guaruntees support through encrypted off-site backups for a minimum of six years (the legal requirement) or when the entity requests data be deleted.
Generate and validate a) Once the classification results are cleaned, the data will be sent to the reporting screen (not to be intervened by other users) where the updated XML will be automatically generated with the requirements for FATCA and CRS of the DGI tax authority. A mirror PDF of the XML will also be created, but with the information in text that is much easier to understand.	YES	The system generates both files: XML to be submitted to the tax authority; and PDF for the bank's own registry use.
b) The system will have a functionality to pre-validate the reports to confirm the XML format to make sure it is error free before uploading them to the DGI tax authority portal.	YES	DTD validation occurs prior to submission.
4. Upload XML reports to the DGI portal. a) Once the XML for FATCA and CRS are validated, they would be ready to be downloaded to be sent in the DGI tax authority portal	YES	System generates final report/s in XML ready to be uploaded to the tax authority portal.
b) Compliance will enter the DGI portal to upload the XML files previously generated from the tool.	YES	CRS/FATCA One provides the ability to upload fully formed XML. This XML can either be marked as "not sent" (new MessageRefIDs will be created) or "sent". XML marked "sent" will retain the MessageRefID to allow updating or voiding of previously sent records.
TECHNOLOGICAL REQUIREMENTS
ARCHITECTURE MANAGEMENT
The system must have an updated technological health platform.
The system must not have flat file interfaces, all integrations must use the latest data encryption technologies.	Yes	All data is encrypted in motion and all data is encrypted at rest.
Data sources can be in any format: relational database, other types of data, integration bus, etc. Integration with flat files is not allowed	Yes	CRS/FATCA One uses a Linux technology stack or a Windows technology stack using several RDBMs or a next generation NoSQL database called MongoDB.
Design and documentation of the Solution architecture model.	Yes	TWC has extensive documentsion
Design and documentation of the required interfaces and conversions.	Yes	TWC's web services API is documented.
Model for data conversion and validation of results.	Yes	All data is delivered in the DGI specified XML format. All XML is validated agains the DTD schema to ensure it is properly created.
Handling structured and semi-structured data natively.	Yes	Data is stored in a Relational or NoSQL database.
Support various encodings, e.g. UTF-8, ISO 8859-1, etc.	Yes	All data is UTF-8, per the DGI requirements.
It must have capabilities to align to the SOA governance model.	Yes	We support SOA model, but we are not familiar with the entity's specific SOA architecture.
It must be scalable. It must be able to add additional compute and storage resources as the volume of data to be managed and processed grows, as well as the number of user requirements that need to be satisfied, all without any downtime, reorganization or data distribution.	Yes	TWC can scale vertically (using larger servers) or horizontally (using Hazelcast for distributed processing and sharding for DB scaling).
Data Dictionary and Entity Relationship Diagram.	Yes	A data dictionary and E/R diagram can be provided.
Data mapping document, which will contain the inventory of source systems that will feed the Datawarehouse or consume the integration platform will feed the Datawarehouse, or will consume the integration platform"	Yes	TWC provides the expected data extract format.
SUPPORT MANAGEMENT
To have a licensing and system support contract.	Yes	TWC sells on an annual subscription basis which includes all support, training, and updates throughout the life of the subscription.
Service Level Agreements (SLA) according to defined priorities (high, medium, low) in order to be able to measure with evidence the supplier's management and performance, (high, medium, low) in order to be able to measure with evidence the management and performance of the service provider during the year prior to contract renewal.	Yes	TWC can provide uptime statistics and provides a SLA for uptime availabity.
Incident Management Model and System Requirements, to have a digital platform that allows the entity's users to access the digital platform that allows the entity users to have access.	Yes	TWC software is available via a highly secure website as a cloud based solution. Incident reports are provided in the case of unexpected downtime.
Every incident must have a root cause, impact, remediation and prevention report.	Yes	Incident reports are provided. In the unlikely event of a data breach that may affect the entity, it is reported within 24 hours of discovery.
All changes implemented in production must be previously approved and certified by the entity. The supplier cannot make any changes without the due change process.	Yes	Since the entity is using a multi-tenant server, all changes are thoroughly tested by our QA department before release. All release notes are provided to all customers.
El sistema debe estar en línea y disponible el 99.99%.	YES	On-line system available all year round. Our SLA is available upon request.
Capacidad de soporte 24/7/365.		TWC provides 24 hour turn-around time on all support requests.
GESTION DE APLICACIÓN
Pruebas de integración y documentación de resultados. Acceso a la integración de datos desde cualquier fuente y el diseño de un proceso eficiente y confiable de integración de datos.	Yes	TWC can provide a test environment for testing and UAT.
The system must be online and 99.99% available.	Yes	On-line system available all year round. Our SLA is available upon request.
The supplier must provide evidence that it has a source code version control standard between the different environments (Development, Test, Production and Contingency). source code between the different environments (Development, Test, Production and Contingency)	Yes	Our development methodology is available upon request. All code is checked into Bitbucket and undergoes a code review from our lead developer, undergoes automated Jenkins test cases, and then is posted as a candidate release. The QA department tests and signs off on the release, and then the Operations Group will deploy to production servers.
A world-class solution for data extraction, transformation and loading (ETL) processes in real time and at any interval, developed and tested according to defined and properly documented technical specifications. defined and properly documented technical specifications.	Yes	TWC provides the data format expected for the data extraction, but the entity would be responsible for identifying data fields in the core accounting system and extracting the data in the correct format.
Test Design and Execution: Document with the executed system test plan for the executed system test plan for solution components and the test and execution log.	Yes	All test plans are document, bugs logged in our JIRA system, and tracked through the bug fixing processes.
A multidimensional database geared to store large volumes of data and with near-instant response times on a centralized platform and with access and audit controls that allow systems auditors to see who and when information is accessed.	Yes	A complete audit log is contained within the application - both for users updating data in the system and for administrators making changes to the system configuration.
Parallel processing to split loads across multiple nodes to speed up queries and transformations on data and increase the number of concurrent users using it. Maximize concurrency.	Yes	TWC can scale vertically (using larger servers) or horizontally (using Hazelcast for distributed processing and sharding for DB scaling).
Ability to measure transaction response time, as well as the availability of the system. Follow-up on cases to measure response times, number of failures and be able to evaluate this service level agreement.	Yes	We have load testing documentation that is available on request. Customers have loaded over 8000000 records.
Minimize latencies. Must be able to provide multiple tiers of caching.	Yes	Multiple tiers of data caching are built into the system. For example, when remediating thousands of records, the remediation screen is returned before all records are pulled from the database.
Model with system availability greater than 95%. The system failure rate should not exceed monthly failures.	Yes	On-line system available all year round. Our SLA is available upon request.
Planning recovery recovery scenarios to ensure system availability in the event of failure. system availability in case of failure.	Yes	Our disaster recovery plan is available on request. Our RTO is 4 hours and RPO 24 hours. Disaster recovery is testing once a year.
ADMINISTRATIVE MANAGEMENT
Mechanisms for the destruction or deletion of information permanently at the end of the contract or at any time during the term of the contract.	Yes	Data is held for at least six year (the legal requirement) and practically until data deletion is requested by the entity. Upon written request all data will be deleted and confirmed within two week of notification to TWC.
Mechanisms for the recovery of the bank's information or data, if the business relationship with the supplier is terminated.	Yes	Data can be exported in many different formats (Excel, PDF, XML, etc..) at all times including prior to the termination of a contract.
System maintenance contract with all information security measures, privacy, SLA definition and SLA non-compliance with penalties defined by both parties.	Yes	TWC is GDPR compliant and can provide our SLA upon request.
INFRASTRUCTURE REQUIREMENTS
As long as the solution is not SaaS it must be able to be run on virtual servers with Windows Server 2016 or higher operating systems and Microsoft SQL 2016 or higher database, IIS as web application server and the application must be able to support encryption of data in transit and at rest.	YES	The system can run support Windows server 2016 and above and can use Microsoft SQL servers as it's database, however CRS/FATCA One is a java based application, and because of that we recommend using java based web servers, the one we recommend is Tomcat, which is open source and free to use.
Mechanisms should already be in place to provide high availability, data backup and disaster recovery and/or a contingency environment.	YES	System hosted by TWC are configured to have high availability, daily data backups and follow our contingency and disaster recovery plans
Support digital certificates. Certificates for TLS server implementations must comply with the X.509 version 3 format (RFC5280). Certificates must be signed with an algorithm consistent with the public key:	YES	The system can be configured for TLS 1.3 and specific Ciphers as required.
Certificates containing public keys such as RSA (encryption or signing key), ECDSA or DSA shall be signed with the same signature algorithms, respectively. - Certificates containing Diffie-Hellman public keys shall be signed with DSA. - Certificates containing ECDH public keys shall be signed with ECDSA.	YES	All signature algorthims are defined by the Panama DGI, but adhere to the latest ciphers.
The system shall support the logging of system events, such as: informational events, error events, security events; as well as the corresponding audit trails that help to track actions or changes made to the system.	YES	The system provides Audit Logs and other reports tha detail the changes made to the system, any changes made to the data, and any system configuration changes.
As long as the solution is not SaaS, the system must support the cryptographic suite defined in the FIPS 140 standard (Federal Information Processing Standard), supported through the native libraries of the Microsoft platform (Secure Channel).	YES	The application follows the FIPS Standards for encryption
The system shall be able to implement TLS 1.2 or higher protocol to protect connections over application protocols including, but not limited to: HTTPS, SMTP, SNMP, LDAP, SFTP, TLS, SSL, SSH, among others.	YES	The system supports all TLS protocols (including 1.1, 1.2, and 1.3) with TLS 1.3 recommended provided the user browsers can support TLS 1.3.
In the case of managed solutions of any type (IaaS, PaaS, SaaS) the supplier must demonstrate that it is able to submit independent SAAE 18 /SOC 1 or SOC 2 Report or ISO 27001, Audit Reports for infrastructure management and operation controls (changes, backups, contingency, etc.).	YES	Our Datacenters have the SOC 2 Type 2 certification report evaluates the controls that meet the criteria for security, availability, confidentiality, and privacy in the American Institute of Certified Public Accountants (AICPA) TSP section 100, Trust Services Criteria. The datacenters also comply with the ISO 27001 internationally-recognized standard for security management best practices and comprehensive security controls
Since it is an exchange of information that may contain personal data, a possible treatment and therefore the PAC provider (Qualified Authorized Provider) must present evidence of its compliance with the principles and minimum standards of personal data protection established in this Agreement, when managing and carrying out the processing of personal data.	YES	Trans World Compliance (“TWC”) is committed to your privacy and support the EU’s General Data Protection Regulation (“GDPR”)
SECURITY REQUIREMENTS
It is required that the system can be integrated with Microsoft Active Directory as a common authentication mechanism either by Same Sing On or Single Sing On using SAML ver 2.0.	YES	The system can be integrated to both Microsoft Active Directory and SAML for SSO authentication
The system shall contain a User Management module that can support the creation, modification and deletion of roles or access groups that restrict certain system functions. The system must allow segregation of roles so that there are always two: someone who logs the transaction and someone who approves it.	YES	The application uses the Spring Security Framework to ensure role based security in the format of Roles and Privileges.
The system must support the two-factor authentication mechanisms integrated to our active directory.	YES	The system supports the use of 2FA and Active Directory.
The system shall include the option to generate security reports with the activities performed by users, reflecting the activities in detail at the data level, for example: A customer identification number was changed, the report should indicate: who made the change, how it was before the change and how it was after the change, time and date of the system, system errors, and changes in the settings and/or parameterization of the application, how the data was before the change and how it was after the change, time and date of the system, system errors and changes that occur in the configurations and/or parameterization of the application.	YES	The system provides Audit Logs and other reports that details any changes made to data (including the user, date/time and change made), as well as any changes made by system adminsitrators to the system configuration.
Application security administrator users should not be able to be assigned transactional roles within the application.	YES	User Roles and Privileges can be configured to accomodate any needs of the institution. Segratation of duties (assignment of roles) is built into the application.
Encryption of user keys in the database.	YES	Data is encrypted in transit and at rest. Highly sensitive data, such as passwords, is further encrypted in the database.
Generate logs and security and audit logs of the users, showing the traceability of the actions performed by each of the users who perform transactions in the system. This also applies to save changes in parameters/configurations of the application. Logs should show in detail the parameter and data modified by the administrator user, its status before and after the change made.	YES	The system provides a wide arrangement of reports and logs to show detailed changes made to the application by the users
Web portals and connections to web services must make use of HTTPS protocol, in case they are published to the Internet they must make use of a known certifying unit.	YES	All web portals support and use the HTTPS protocol, and have SSL certificates signed by Digicert
Sanitization of input fields on data entry screens.	YES	Data validation is done on all fields. For example, GIIN numbers and TIN numbers are validated.
The supplier must have a contingency and backup scheme for the system and data, in case of failures.	YES	TWC disaster recovery documentation is available upon request. Offsite encrypted backups are stored and can be used to ensure a RTO of 4 hours and RPO of 24 hours.
In the case of SaaS and personal data access/processing solutions, the vendor must confirm that it is able to provide independent audit reports such as: SSAE18 /SOC1 or SOC 2 Reports for operational controls, security and vulnerability management, or Certified in PCI, ISO 27001, Audit Reports and internal controls audits performed annually by a third party. If you do not have them, you must allow audits by the Bank to verify the operational controls implemented to ensure the management and privacy of the Bank's customer data.	YES	Our Datacenters have the SOC 2 Type 2 certification report evaluates the controls that meet the criteria for security, availability, confidentiality, and privacy in the American Institute of Certified Public Accountants (AICPA) TSP section 100, Trust Services Criteria. The datacenters also comply with the ISO 27001 internationally-recognized standard for security management best practices and comprehensive security controls
RISK MANAGEMENT
It is required that the system can be integrated with Microsoft Active Directory as a common authentication mechanism either by Same Single On or Single Sign On using SAML ver 2.0.	YES	The system can be integrated to both Microsoft Active Directory and SAML for SSO authentication
The system shall contain a User Management module that can support the creation, modification and deletion of roles or access groups that restrict certain system functions. The system must allow segregation of roles so that there are always two: someone who logs the transaction and someone who approves it.	YES	The application uses the Spring Security Framework to ensure role based security in the format of Roles and Privileges.
The system must support the two-factor authentication mechanisms integrated to our active directory.	YES	The system supports the use of Active Directory, and it can be used as two factor authentication
The system must include the option to generate security reports with the activities performed by the users, reflecting the activities in detail at the data level, for example: A customer identification number was changed, the report must indicate: who made the change, how the data was before the change and how it was after the change, time and date of the system, system errors and changes that occur in the configurations and/or parameterization of the application.	YES	The system provides Audit Logs and other reports tha detail the changes made to the system and it's data
Application security administrator users should not be able to be assigned transactional roles within the application.	YES	User Roles and Privileges can be configured to accomodate any needs of the institution
Encryption of user keys in the database.	YES
Generate logs and security and audit logs of the users, showing the traceability of the actions performed by each of the users who perform transactions in the system. actions performed by each of the users who perform transactions in the system. This also applies to save changes in parameters/configurations of the application. Logs should show in detail the parameter and data modified by the administrator user, its status before and after the change made	YES	The system provides Audit Logs and other reports that details any changes made to data (including the user, date/time and change made), as well as any changes made by system adminsitrators to the system configuration.
Web portals and connections to web services must make use of HTTPS protocol, in case they are published to the Internet they must make use of a known certifying unit.	YES	All web portals support and use the HTTPS protocol, and have SSL certificates signed by Digicert
Sanitization of input fields on data entry screens.	YES
The supplier must have a contingency and backup scheme for the system and data, in case of failures.	YES	TWC disaster recovery documentation is available upon request. Offsite encrypted backups are stored and can be used to ensure a RTO of 4 hours and RPO of 24 hours.
In the case of SaaS solutions and access/processing of personal data, the supplier must confirm that it is able to provide audit reports type: SSAE18 /SOC1 or SOC 2 Reports for operational security controls and vulnerability management, or Certified in PCI standards, ISO 27001 Audit Reports and internal control audits performed annually by a third party. In case you do not have them, you must allow audits by the Bank to verify the operational controls implemented to ensure the management and privacy of the Bank's customers' data.	YES	Our Datacenters have the SOC 2 Type 2 certification report evaluates the controls that meet the criteria for security, availability, confidentiality, and privacy in the American Institute of Certified Public Accountants (AICPA) TSP section 100, Trust Services Criteria. The datacenters also comply with the ISO 27001 internationally-recognized standard for security management best practices and comprehensive security controls
DATA REQUIREMENTS
Comply with the data requested by the DGI data sheet.	YES	CRS/FATCA one provides all the information as requested by the DGI.
The application shall perform the homologations of the data catalogs of the data source with those values required by the application.	YES	CRS/FATCA one provides all the information as requested by the DGI and in the format requested by the DGI.