In the Dominican fintech sector, there is a scene that repeats itself with uncomfortable and astonishing precision. An entrepreneur with extensive leadership and real visibility within the fintech and factoring ecosystem in the Dominican Republic and the Caribbean recently described it to me like this, without drama because he has seen it too many times:

"Look, Carlos, we paid for the entire development. We launched our functional app. And a few weeks later, an app that's too similar appears... but with a different logo."

The most disturbing thing is that, almost always, it doesn't start with bad intentions. It starts with an operational decision that seems "practical" and ends up being lethal: leaving control where it shouldn't be.

Sometimes the developer is external (third-party programmer, consultant, application development company). Other times, they are internal (salaried employee). The contract changes, but the risk remains the same. If a person or third-party company controls the repository, cloud, keys, and deployments, the fintech company may have paid for everything and still operate as a guest on its own product.

And in software, paying is not the same as owning.

The Part That No One Bills: Learning That Becomes a Competitive Advantage

A fintech doesn't buy "code." It buys interaction. It buys operational decisions refined by iteration. It buys the real onboarding funnel (where people actually drop off). It buys the exact order of KYC validations and the exceptions that only appear when traffic and rare cases arrive. It buys anti-fraud thresholds tuned by cohorts. It buys idempotence and reversals that prevent double charges. It buys reconciliation that doesn't break when the upstream fails. It buys the how of sensitive integrations (gateway, core, KYC/AML, webhooks).

Buy playbooks: What to look at first when incidents occur, what to shut down, what to limit, what to let breathe. That muscle, your way of operating, is what has the most value. And that's why it's the first thing that "miraculously" appears in another app with purely cosmetic or UI changes.

The Second Scene, the One That Hurts the Most

It's not when you suspect it. It's when they confirm it.

It usually arrives as a link in a chat. A "check this out" from someone in the industry. An investor asking why two products "feel the same." Or a demo where someone unintentionally navigates the same flow with the same validation order, the same key screens, the same rules.

You don't see a crude copy. You see a functionally equivalent replica with a different logo. That's white copying.

What really hurts is realizing that you not only paid for success (a functional app), but also financed every previous failure that led to it: you paid for the hours spent debugging mistakes, subsidized the failed iterations that are now perfect workflows, and covered the learning curve that now allows that developer to deliver a mature solution to a third party at a fraction of the cost and time. Seeing that "white copy" in a WhatsApp chat or in an email link is confirmation that you were, without knowing it, the sponsor of your competition's technical mastery; you put up the capital to find out what worked and what didn't, allowing someone else to skip the ordeal of experimentation and start directly from the goal that cost you time and thousands or millions of dollars.

Dominican Republic: Law 65-00 Protects You, but Requires You to Act Like an Owner

In the Dominican Republic, computer programs are protected by copyright, and Law 65-00 expressly includes "computer programs" as well as "technical documentation and user manuals" related to software.

Now, here comes the part that most people learn late: Copyright does not reward you for having paid; it rewards you for having left a legal and operational trace of your property.

Two provisions of Law 65-00 are often the breaking point for fintechs:

The "producer" of the program

Article 73 defines the producer as the person who takes the initiative and responsibility for the production; it presumes that the producer is the person indicated "in the usual manner"; and, unless otherwise stipulated, it presumes that the exclusive economic rights, including adaptations or versions, are assigned to the producer.

Operational translation: If the repository lives in the developer's organization, if the cloud is in their name, if they decide on the keys and deployments, if the critical documentation "lives on their laptop," you yourself are building the perfect scenario for dependency... and for litigation from below, and almost always too late.

Copyright protects expression, not business methods.

Law 65-00 excludes ideas, procedures, methods of operation, and concepts from protection (Article 7).

That phrase explains modern pain: The clone "isn't the same," but it feels the same, because it replicates logic and flow even though it rewrites the code and changes the UI.

The Mistake That Hurts Both Worlds: External Developer and Employee Developer

This is where many people make mistakes due to overconfidence.

External developer

The typical pattern is simple: The repo is "the developer's," cloud billing is "the developer's," the pipeline is handled by "the developer," and documentation is "pending." Result: You cannot audit, migrate, or operate without permission. And from there, turning your project into a template is too easy: one branding adjustment, two cosmetic changes, and a "new" fintech emerges.

Employed developer

The trap is psychological: "Since I'm on the payroll, everything is mine." The law can help, but the business breaks down due to access. If the employee works with personal accounts (personal Git, personal Drive, personal Apple ID, "quick" cloud accounts), or if there is no clear corporate account policy and serious offboarding, recovering digital assets becomes a probative and operational nightmare.

And here's the uncomfortable truth: Modern whitewashing doesn't start with lawyers; it starts with access.

Where the Intelligent Clone Fell: Trade Secrets and Unfair Competition

When the white copy is not a literal copy/paste, what is recycled is usually what you would never publish: thresholds, scoring, rules and exceptions, parameterizations, mappings, fraud patterns, configurations, security architecture, fine risk decisions, operating procedures.

This is where Law 20-00 comes in. Article 178 defines trade secrets as confidential information (not generally known or easily accessible) with commercial value because it is confidential, for which reasonable measures have been taken to keep it that way. And Article 179 classifies as unfair competition, among other behaviors, the unauthorized exploitation or disclosure of a trade secret that was accessed under an obligation of confidentiality arising from a contractual or employment relationship.

The actual clone move doesn't start in the code. It starts with access.

Five White Anti-Copy Contractual Locks That Will Stand Up in Court

This is where a fintech that complains differs from a fintech that charges. These clauses are not just for show. They are clauses used in highly developed markets such as the US so that if "the app with another logo" appears, the discussion is short, verifiable, and expensive for the cloner.

First lock: Unambiguous producer, but with an operational footprint

It must be stated that the fintech company takes the initiative and responsibility for the project and therefore acts as the producer of the program under Article 73 of Law 65-00. And then comes what really pays off: that the fintech company appears as the producer "in the usual way" (corporate repository, documentation under corporate branding, deliverables with company identification, corporate control of deployments).

Second safeguard: Total transfer of assets and unambiguous right to transform

In fintech, "the software is delivered" means nothing if tomorrow someone tries to make a graceful exit: "That's another version." The transfer or assignment of assets must cover exploitation and, above all, modification, adaptation, versions, and derivatives.

Third restriction: Prohibition of reuse and repackaging for third parties

The contract must expressly prohibit the reuse, repackaging, licensing, resale, or making available to third parties of the product, modules, components, or deliverables created for the fintech, unless authorized in writing. This lock renders the typical defense ("I didn't copy your code") insufficient: Here, the lawsuit is not about copying; it is about exploiting for a third party what was exclusively yours.

Fourth lock: Anti-functional equivalent, designed to kill the "not equal"

Define "functional equivalent" as any solution that substantially reproduces flows, sequences, validations, rules, exceptions, risk logic, integrations, and parameterizations developed or refined in the project, even if the UI/branding changes or the code is rewritten.

Why is this crucial in the Dominican Republic? Because, as a general rule, Law 65-00 excludes ideas, procedures, methods of operation, and concepts from protection (Article 7). If you don't tie it down with a contract, the infringer will argue that what was replicated was a "method" and not "expression."

Fifth lock: Operable trade secrets, not just on paper

Identify in the contract (and in the employment framework, if applicable) what constitutes sensitive information: thresholds, scoring, anti-fraud rules, AML triggers, configurations, mappings, runbooks, security architecture, data dictionaries, and operational learnings. Then impose a double obligation: Do not disclose and do not use outside the project. And, above all, enforce reasonable verifiable measures, because without that, secrecy becomes rhetoric: Role-based access control, segregation of environments, formal management of secrets, traceability of critical changes, and an offboarding plan with asset handover and access revocation.

ONDA and ONAPI: Each in Their Own Lane, to Strengthen Your Position

ONDA deals with copyright and offers registration of works, which is useful as evidence. The law already classifies software and its documentation as protectable; registration does not replace control or contract, but it helps to establish existence and authorship.

ONAPI is your industrial property lane. Many white copies change the logo precisely to avoid trademark friction. That is why robust defense is almost never "one thing": it is based on contract, control, copyright (Law 65-00), and trade secrets/unfair competition (Law 20-00).

Conclusions