stuff

log.md

@@ -1,5 +1,99 @@
 # Log
 
+## 2025-08-13
+
+### Meeting with Luis
+
+- We sit down to discuss UIF:
+    - Report docs: (https://drive.google.com/drive/folders/17dhJdF5cUDT50g4-FhAEaonqatH8SMzR)
+    - Law: https://drive.google.com/file/d/1gQ8F96C_kmJe7oLvXxML7CODjPE32zun/view
+- Open topics
+    - Does the documentation in these files cover 100% of what we need to do, UIF wise? Or should we add anything in there?
+    - Are these docs up to date?
+    - What does "having" these reports mean? Is file generation good enough for an audit? Do we need to worry about integrating with UIF systems earlier than launch?
+    - Are there any XSD validation files somewhere, like the ones from the Central de Riesgos? 
+        - No.
+        - We should build it.
+    - Confirm that the Excel templates and the PDF forms are just illutrative and not really relevant for our case
+- Propose that I build an inventory of what needs to be built and how it could be reviewed before going crazy with implementing, and that we all agree on it (including Luis)
+- best way to communicate
+
+Also generate in Excel so they can be reviewed by Marcos
+
+we are missing transfer365 report details, do we care
+
+reportes de efectivo -> we don't need to do since we don't do cash
+
+otros medios -> cheques, debitos, etc
+
+otros medios electronicos is the only applicable 
+
+we need to clarify tipo de producto
+
+Oficial Cumplimiento -> Marco (quien es Marco?)
+    - actividad economica -> uses a different catalogue than the one used for KYC, we need to develop a mapping
+
+you usually need to report the teller's identity. In our case, we can add a generic "banca electronica" identity. Unless it's a "manual", accounting driven (not UI driven) operation, in which case we would need the "oficial del banco" identity. We will need to add a field for usernames, since we right now only have email.
+
+Do we need to create the human readable forms?
+
+Should we check absolutely any transaction above the thresholds
+
+Reporting suerly applies to the current account transactions, but not to the collateral account. We should confirm with Marcos. Perhaps on liquidation?
+
+
+#### Clean notes after meeting
+
+- On which reports we need to do:
+    - We have confirmed with Luis that we need to generate the 5 reports here (https://github.com/GaloyMoney/knowledge-base/pull/14/files).
+        - Yet it seems only `07 UIF Método Reporte Diario de Otros Medios Electrónicos.pdf` applies to us given that all of our operations are digital.
+        - `03 UIF Método Reporte Diario de Efectivo` and `04 UIF Método Reporte Mensual de Efectivo` only apply to physical cash transactions, so they don't apply to Volcano since it doesn't handle cash.
+        - `05 UIF Método Reporte Diario de Otros Medios` and `06 UIF Método Reporte Mensual de Otros Medios` apply to other bank methods such as checks.
+    - He also mentioned that there is a sixth report, not listed there, related to the transfer365 payment rail. He doesn't have details on that report at the moment, but thinks it doesn't apply to us since we don't do transfer365 transactions.
+- On how we need to deliver it:
+    - The end stage in production is to integrate with the UIF systems via XML delivery, but this will only happen when we're actually launching.
+    - For the current stage and to satisfy the audit, we will simply produce files.
+    - Technically, we need to produce XML files as described by the UIF documentation. But we will also produce CSV-structured exports that are easy to consume by humans so that auditors and regulators can easily check the info (this has been explicitly recommended by Luis).
+- On validation:
+    - We are not aware of the existence of any `xsd` files that we can use to validate the XML files that we must deliver to the UIF. I would propose building them ourselves according to their spec so we have something to validate against.
+- On the applicability to collateral accounts:
+    - Luis considers that the transactions on the collateral account don't need to be reported, since they are not really change of ownership but rather just the delivery of a collateral. He equates it to how setting a house as collateral for a mortgage doesn't trigger any reporting to the UIF.
+- On identifiying parties:
+    - When reporting a transaction, the details of everyone involved must be reported. This means that if a Volcano client receives a bank transfer of some third party to his USD account, we would need to have the personal details of that third party.
+    - Given that we don't currently have any way to collect that, we need to either:
+        - Expand `lana-bank` features to be able to do that.
+        - Or simply have the convention that customers can only send/receive USD from other accounts under their name.
+- On identifying tellers:
+    - The reports expect us to inform who in the bank handles the transaction.
+    - Given that our operations are driven by a digital app, Luis suggests that we simply use some "Electronic Banking" generic identity, since generally there is no human at the wheel.
+    - But if we make transactions manually, for instance by having a Volcano employee do a transfer between different customer accounts in the bank manually via accounting, then we would be expected to inform the identity of the particular employee who did that.
+- On the professional activity mapping:
+    - The UIF has a different taxonomy for customer profession that the one used in KYC. This needs to be added to the customer data in the transaction reports.
+    - We need a mapping between the KYC taxonomy and the UIF one so we can translate that in our reports and send the UIF the codes they expect. Either Luis gets it from somewhere or we painfully build it ourselves.
+
+Open actions:
+- Confirm to a 100% that we only need to do report `07 UIF Método Reporte Diario de Otros Medios Electrónicos.pdf`.
+- Confirm if other reports need to simply be delivered empty, or not at all.
+- Discuss with the team if we're comfortable with restricting USD transactioning with other accounts to accounts under the name of the same customer.
+- Clarify where do we get the profession code mapping between KYC codes and UIF codes.
+- Build the reports.
+
+
+## 2025-08-08
+
+### Feedback with Justin
+
+Stuff I'm enjoying:
+- Great engineering practices and culture
+- First row seat on Bitcoin adoption
+- International team
+
+Stuff that feels sour:
+- Confusion with urgency but not rushing?
+- Timezones are a challenge
+- For now I've been cautiously backing off, but I'll probably become a bit more noisy
+- I would love to interact directly with the client when it makes sense
+
 
 ## 2025-07-30