Weekly Updates

Four comments about Colombia's upcoming Open Finance regulation

Last week, Colombia regulators held a call for comments on the draft regulation of Open Finance. The goal of the regulation is to create a legal framework in Colombia to allow consumers to give third-party providers access to their financial data. Here are four comments on the draft regulation:

Comment #1: Participation from banks and third-party providers is optional

Colombia has followed Brazil, the UK, and Australia in creating regulations for data portability in the finance sector. Colombia has also defined a technical standard to govern these interchanges. But unlike these countries, Colombia is not currently forcing banks to participate. That could risk banks participation stalling to a halt.

However, the draft regulation does allow financial institutions to share data with third-party providers. This is different from Brazil, where regulators restricted access to the open finance ecosystem to non-regulated companies. Colombia's draft regulation explicitly allows access and also prohibits regulated entities from arbitrarily restricting access to data by third-party providers that comply with regulations.

Does this mean regulated entities have to allow third-party access to customer data on request? We'll have to wait and see.

Comment #02: Indirect regulation approach

The draft regulation adopts an approach like Brazil's Central Bank in dealing with non-regulated entities. Since financial regulators cannot mandate non-regulated companies, the draft regulation makes regulated entities adhere to obligations whenever they deal with non-regulated companies. This way, financial regulators can supervise the regulated company's contracts and hold them accountable for misdeeds by non-regulated entities. The benefit of this indirect regulation approach is that it allows regulators to insert greater protections into the ecosystem without having to shut out third-party providers.

Comment #03: Policy-based approach

The draft also follows Brazil's Central Bank in not creating an overly restrictive one-size-fits-all regulation. Instead, institutions must create their own policies and manuals based on the regulator's guidelines. This allows companies to set requirements suited to their size and risk instead of dealing with complex controls that the riskiest regulated entities must follow. Regulators can supervise the quality of the policies, and whether institutions implement the controls and procedures they said they would. We are also big advocates for a risk-based approach in regulation, and the policies mechanism is a great way to do that.

Comment #04: Technical standard

Regarding the technical standard, the draft follows the most common standards in the market today, such as RESTful APIs in JSON, using ISO 20022, and OAuth 2.0 + FAPI 2.0 for authentication. We applaud the less obvious choice of mandating m-TLS on all communications. However, we have some reservations with ISO 20022, OAuth, and FAPI, which we will explain in a future article. We are also currently analyzing better ways to exchange data without relying on this now-standard API model.

What puzzles us the most, though, is the apparent absence of a more detailed definition of communication between participants. This could make implementation costs very high and the entire ecosystem highly dependent on intermediaries that make the connection to banks in the lack of a proper standard communication protocol.

ChatGPT use case analysis — The issue of output supervision

Joshua Browder published a compelling use case of GPT-4 to partially automate life bureaucracy: use his DoNotPay tool with GPT-4. He goes over four different automation in that Twitter thread that help him save around USD 200. He had GPT-4 help him review his subscriptions, cancel a gym membership, find a transaction where he could get an easy refund, and help negotiate his Comcast subscription. They all showcase GPT's ability to interact and negotiate with real people to produce cost reductions. But while the first two are pretty straightforward, the refund and subscription price reduction deserve a closer look.

In the refund case, the GPT-generated text references the Federal Trade Commission Act. While that reference is reasonable in this case, legal accuracy is not guaranteed. In the Comcast negotiation, a similar effect happens, where the GPT-generated text includes information about outages and uses it to negotiate a price reduction as compensation for the outages. While the outages and alleged damages may be genuine, that is also not guaranteed and require additional input from the operator.

The potential tools like GPT-4 have to reduce the cost of bureaucracy is incredible. It shines especially in cases where companies have no incentives to make it easier for consumers, such as cancellation and renegotiation. But we need to remember that while a machine produced the text, the user is the one communicating it, which means they are liable for any misbehaviors. Tools such as GPT-4 can make up information and, if communicated to third parties without supervision, it can have terrible consequences — as they should. The day we allow people to misrepresent the truth by proxy is the day all good faith expectations disappear.

A safer way to use such tools is in a supervised manner. The user asks the model to generate a start point automatically and then reviews (supervises) what was produced, verifying and ensuring it does what the user wants and not what was most likely probabilistically. This is the way most companies use AI today. The AI model produces decisions, and the company monitors that the decisions follow the company's standards. This is primarily used in decision models, such as credit risk models, but the same logic applies to any probabilistic structure, such as GPT. By itself, a model can degenerate into probabilistic garbage with real-life consequences. With supervision, it can be an exceptionally powerful asset.

SME and Ransomware

This podcast from The European Union Agency for Cybersecurity (ENISA) is a good resource for understanding the dynamics of ransomware and how it evolved. Unfortunately, the podcast’s participants fell into the trap of considering SMEs as a single uniform type of company. They failed to provide actionable techniques for the different types of SMEs. That said, the information available is still good when considering ransomware in developing a security strategy.

One such piece of information is the ransomware evolution over the years. Today the attack can involve multiple extortion phases:

Phase 1: A virus encrypts the victim’s data and asks for money (usually some cryptocurrency) for the decryption key. This is an entirely indiscriminate automated attack.
Phase 2: Compounding on phase 1, the virus also steals the victim’s data, and the victim needs to pay more not to have the data leaked or sold. This is also mostly automated, but to maximize the price for data, choosing the right marketplace to sell the data is important and more involved as the data needs to be somewhat analyzed.
Phase 3: This one is even more involved. The attacker goes through the exfiltrated data from Phase 2, looking for supposedly illegal activity, and blackmails the victim into paying a third time to prevent the attacker from reporting the allegedly illegal activity to authorities. This is primarily manual work done by the attacker to maximize the return on the attack.

Another interesting part is the discussion about paying or not for the ransom (or the subsequent attack phases). While Europol does not recommend paying because that payment will fuel the next ransomware attack, they also understand that the victim will pay if the consequences are a severe business disruption. Paying or not, Europol recommends notifying authorities about the ransomware so law enforcement can work to disrupt further attacks.

In terms of general recommendations to prevent or reduce damages from ransomware attacks, they follow the current mantra of having backups, keeping software up-to-date, having an antivirus, and enforcing a least-privilege access policy. There is the addition of 2FA as a strong deterrent for the attack since it is harder to bypass 2FA, meaning attackers tend to shift to different targets when faced with a 2FA defense.

Even though their recommendations are effective if implemented correctly, this is precisely where clumping all SMEs together makes recommendations fall apart. A 200-person tech company with the right incentives probably has the people and expertise to take those recommendations, produce a security strategy, and implement it. But a 10-person small restaurant definitely does not.

Colombia and OpenFinance, not-so-AutoGPT, and Ransomware