Financial Technology and Payments IP Toolkit: Eligibility, Market Data, Models, and Interfaces

By Casey Scott McKay · 2025-11-11

Financial technology sits at the intersection of the least favourable patent eligibility environment in the system and the most heavily licensed data in commerce. This toolkit assembles the working material for practitioners advising payments companies, trading platforms, lenders, and the vendors who serve them. It covers where patent claims survive the eligibility analysis and where they do not, the market data licence terms that quietly govern every product built on an exchange feed, and the model governance obligations that convert an algorithm into a regulated artefact. It sets out the open banking and interface layer, the customer data rights that follow, and the payment network rules that operate as private law. It closes with clause language, an authorities table, and the failures that recur.

IP and Technology > Information Technology | Toolkit | Published 11 November 2025 - Updated 31 January 2026 | Casey Scott McKay - marksy.us

Summary. Financial technology occupies the least favourable patent eligibility environment in the system and the most heavily licensed data environment in commerce, simultaneously. This toolkit covers where claims survive Alice, how exchange and vendor data licences constrain products built on them, what model governance obligations do to an algorithm, how open banking interfaces and screen scraping allocate customer data rights, and how payment network rules function as private law that overrides commercial drafting.

Keywords: fintech IP · patent eligibility · Alice step two · market data licences · non-display use · model governance · algorithmic decisioning · adverse action notices · open banking · screen scraping · customer data rights · payment network rules · trading system secrecy · vendor terms · regulated brand clearance

Start Here

Two structural facts define this practice, and almost every problem descends from one of them.

The first is that the core inventions are the hardest thing in the patent system to claim. A method of matching orders, assessing credit, detecting fraud, routing a payment, or pricing a derivative is, at its heart, a way of processing information about money. Alice Corp. v. CLS Bank International concerned a financial intermediated settlement claim and produced the framework that has since invalidated more financial technology patents than any other doctrine. The Federal Circuit's application in Bilski v. Kappos, and before that the machine-or-transformation discussion in In re Bilski, set the tone; Ultramercial, Inc. v. Hulu, LLC and buySAFE, Inc. v. Google, Inc. confirmed it.

The second is that the data the products run on is licensed, not owned. Market data comes from exchanges and vendors under agreements with display, non-display, redistribution, derived data, and audit provisions that most product teams have never read. Consumer data comes with statutory constraints. Transaction data comes with network rules. A fintech company's product is frequently built on inputs it holds under terms it did not negotiate and cannot change.

Everything else follows.

Where the patents fail, trade secrecy carries the weight. Trading algorithms, risk models, fraud heuristics, and pricing engines are protected under 18 U.S.C. § 1836 precisely because they cannot be patented and because their value would be destroyed by publication. The reasonable measures analysis of Rockwell Graphic Systems, Inc. v. DEV Industries, Inc. is the operative discipline, and the sector's employee mobility patterns make it a live one.

Where the data is licensed, the licence is the product's constraint. A derived data product built in breach of an exchange licence is an audit finding, a back-payment, and sometimes a termination.

Where the algorithm makes a decision about a person, it becomes a regulated artefact. Explainability, adverse action notices, fair lending analysis, and model risk governance apply, and they interact awkwardly with trade secret protection.

And where money moves, network rules apply — private contractual regimes that bind participants, prescribe branding, control data use, and allocate liability, with no negotiation available.

Four questions organise the work.

Is there anything patentable here, and if so, how should it be claimed?

What do the data licences permit, and does the product exceed them?

What obligations attach to the model because of what it decides?

And what do the interface and network rules require that the commercial contract does not mention?

See Money Is Software Now for the doctrinal treatment, Advising a Fintech or Payments Business for the sequence, and the Financial Technology IP Checklist for the working list.

Part one: eligibility, and what survives

The framework. 35 U.S.C. § 101 as construed in Alice Corp. v. CLS Bank International and Mayo Collaborative Services v. Prometheus Laboratories, Inc.: is the claim directed to an abstract idea, and if so does it contain an inventive concept sufficient to transform it into a patent-eligible application.

What fails, reliably. A method of performing a financial transaction with generic computer implementation. A method of collecting, analysing, and displaying data. A method of organising human activity — hedging, escrow, settlement, credit scoring — recited at a level of generality that describes the goal rather than a mechanism. Adding "on a computer", "over a network", or "using a distributed ledger" changes nothing.

What survives, in practice. Claims that solve a technical problem in a technical way, following the line from Enfish, LLC v. Microsoft Corp. and DDR Holdings, LLC v. Hotels.com, L.P.. In the financial context, that means claiming the infrastructure rather than the finance: a specific data structure that improves database performance; a network architecture that reduces latency in a measurable way; a cryptographic protocol with a specific construction; a hardware or memory arrangement; an error detection and recovery mechanism; a specific security technique.

Drafting notes.

Claim the mechanism, not the outcome. "Determining creditworthiness" is an outcome. "Constructing a sparse feature matrix using the following indexing scheme, which reduces query time by avoiding a full table scan" is a mechanism.

Describe a specific technical problem in the specification and state how the invention solves it. Enfish turned on the specification's account of a technical improvement, and specifications drafted without one give the examiner and the court nothing to work with.

Recite structure with particularity. Generic processors and generic memory are the hallmark of an ineligible claim; a specific architecture is not.

Avoid result-oriented functional language at the point of novelty, which also engages 35 U.S.C. § 112(f) and the written description problem in Williamson v. Citrix Online, LLC.

Consider whether the invention is better protected as a trade secret. A trading algorithm that is undetectable in use, and whose value depends on secrecy, should not be published in an application that may not issue.

Covered business method review is gone but post-grant challenges remain, and financial patents attract inter partes review at high rates. See The Second Look.

And prior art in this field is unusually diffuse — academic finance literature, exchange rulebooks, vendor documentation, and standards bodies — which makes the search harder and the 37 C.F.R. § 1.56 duty of disclosure more demanding. See the Duty of Candor Checklist.

Part two: market data licences

The single most under-read document in a fintech company is the exchange or vendor data agreement, and it governs what the product may be.

The categories that matter.

Display use — showing data to a human on a screen — is priced per user, per terminal, or per entitled device, and is audited by user counts.

Non-display use — data consumed by an algorithm without human display — is the category that has grown fastest and is priced separately and often punitively. Automated trading, risk calculation, pricing engines, index construction, order routing, and analytics all fall within it, and a firm that licensed for display and then built an algorithm has a back-payment exposure.

Derived data — outputs computed from licensed inputs — is defined narrowly by most exchanges. A number computed from a licensed price is frequently still licensed data, and the definition of what ceases to be derived is contractual rather than logical.

Redistribution — providing data onward to customers — requires separate permission, separate reporting, and frequently a separate agreement per downstream recipient.

Internal use and affiliate use are defined, and a group structure that shares a feed across entities without permission is a standard audit finding.

Audit rights are exercised routinely, not theoretically. Exchanges and major vendors run audit programmes with defined lookback periods, and settlements are common enough to be a budgeted cost in large firms.

Practice notes.

Map every feed to every product before signing anything, and re-map when a product changes.

Ask the non-display question about every automated process, including internal risk and compliance systems that nobody thinks of as a product.

Read the derived data definition and test it against the actual output. Where the answer is genuinely unclear, ask the exchange in writing, because a documented position is a defence and a silent assumption is not.

Track entitlement counts as a live control rather than an annual reconciliation.

Negotiate the audit lookback and the remedy structure where any leverage exists.

Address termination: what happens to historical data, to models trained on it, and to products that depend on it. This is the term that determines whether a product can outlive its licence.

The underlying legal position is that the data is contractual, not proprietary. Facts are not owned — Feist Publications, Inc. v. Rural Telephone Service Co. — and the sports analogue in National Basketball Ass'n v. Motorola, Inc. narrowed misappropriation to a thin residue. What protects an exchange feed is access control and licence terms, which is why the terms are strict. The framework is the same one described in Selling Something You Cannot Own and the Data Licensing Checklist.

Part three: models, algorithms, and the regulated decision

An algorithm that decides something about a person acquires obligations that have nothing to do with intellectual property and that constrain how it can be protected.

Adverse action and explainability. Where a model contributes to a credit decision, the applicant is entitled to specific reasons. A model whose reasons cannot be articulated is not deployable, whatever its accuracy, and "the model said no" is not a reason. This is the sharpest practical conflict between trade secret protection and regulatory obligation in the sector.

Fair lending analysis. Disparate impact testing across protected classes, applied to model outputs and to the features that drive them. Proxy variables are the recurring problem — a feature correlated with a protected characteristic produces the same effect as using the characteristic.

Model risk governance. Development standards, independent validation, documentation, monitoring, and periodic review, with a model inventory and an owner for each. Regulated institutions have supervisory expectations here; their vendors inherit them by contract.

Vendor models are the hard case. A lender buying a third-party scoring model must satisfy its own explainability and validation obligations using a model the vendor will not describe. The workable answer is a documented validation package, reason code mappings, performance monitoring data, and audit rights — negotiated at procurement, because there is no leverage afterwards. See Buying a Model.

Training data provenance matters for both regulatory and intellectual property reasons: what it was, whether the rights permitted this use, and whether any of it was scraped. See the Data Collection and Scraping Risk Checklist.

And the trade secret position must be built deliberately. 18 U.S.C. § 1836 protects what is treated as secret, and the reasonable measures analysis of Rockwell Graphic Systems, Inc. v. DEV Industries, Inc. applies. In a sector where quantitative staff move between firms constantly, that means access segmentation, marking, onboarding and exit discipline, and an honest view of what is genuinely secret versus what is industry knowledge. See Building a Trade Secret Program That Survives Litigation and the Restrictive Covenant and Departure Checklist.

Part four: interfaces, open banking, and customer data

The direction of travel is toward permissioned interfaces and away from credential-based access. Screen scraping using customer credentials worked, scaled, and created security and liability problems that regulators and banks both wanted to end.

Access rights. Where a regime confers a consumer right to authorise data sharing, the interface obligations follow: availability, format, scope, and prohibitions on discriminatory access.

Credential sharing is the legacy problem. A third party holding a consumer's banking credentials operates outside the bank's authentication model and is generally in breach of the bank's customer terms, with the consumer bearing the liability allocation risk.

Computer access claims are narrower than firms assume. 18 U.S.C. § 1030 was narrowed by Van Buren v. United States, and access to publicly available data was addressed in hiQ Labs, Inc. v. LinkedIn Corp.. Terms of service breach and contract claims frequently do more work than the statute. See Running or Defending a Data Scraping Program and Who Owns the Data.

API terms are the operative instrument for permissioned access: scope, rate limits, permitted use, prohibition on secondary use, security requirements, certification, liability allocation, and termination. Negotiate them as contracts, not as documentation.

Interface specifications and standards raise the ordinary interoperability questions, with the copyright analysis after Google LLC v. Oracle America, Inc. supporting reimplementation in defined circumstances.

Consumer financial data carries statutory obligations on privacy notices, safeguards, and vendor oversight, alongside state comprehensive privacy statutes with sensitive category treatment.

And the terms of service themselves must be formed enforceably, which is a recurring failure in consumer fintech. See Terms That Actually Bind.

Part five: payment network rules as private law

A payments business operates under rulebooks that function as binding law and are not negotiable.

Branding and mark use are prescribed: acceptance marks, placement, size, colour, and co-branding rules, with approval processes and enforcement. A merchant or issuer that deviates receives a notice, not a negotiation. The trademark analysis is ordinary licensing; the practical position is compliance. See Branding Money.

Data use rules constrain what participants may do with transaction data, including limits on secondary use and on sharing with affiliates. These override commercial arrangements a fintech may have agreed with a partner.

Security standards are contractual, audited, and carry financial consequences for non-compliance, including liability shifts after an incident.

Liability allocation for fraud and chargebacks is set by the rules and by the relative security posture of the parties, not by the parties' own agreement.

Certification and registration gate market access. A programme manager, a processor, or a service provider must be registered and certified, and the process is a genuine barrier.

Rule changes are unilateral and effective on notice, which means a product built on a current rule may need rebuilding on a schedule the business does not control.

Practice note. Read the applicable rulebook sections before designing a product, not after. The most common expensive mistake in payments product development is a design that violates a rule nobody consulted, discovered at certification.

Part six: brand, naming, and the approval layer

Financial services brands face pre-clearance and disclosure regimes that ordinary consumer brands do not.

Naming restrictions apply to terms implying banking, insurance, or particular regulated status, with statutory prohibitions on misleading use.

Disclosure and advertising review obligations apply to marketing communications, with pre-approval requirements for some categories and record retention for all.

Trademark clearance must run alongside regulatory clearance, and a mark that clears the register may still be unusable because of a naming rule. Run both searches together. See Clearing and Launching a Financial Services Brand and the Financial Services Branding Checklist.

Registration follows the ordinary path under 15 U.S.C. § 1051 with the bars in 15 U.S.C. § 1052, and infringement analysis under 15 U.S.C. § 1114 and 15 U.S.C. § 1125.

Descriptiveness is the recurring obstacle, because financial brands gravitate toward words describing what they do.

And the approval toolkit for pre-clearance regimes generally sits in the Brand Name Approval Toolkit and, for adjacent regulated sectors, the Regulated Industry Branding Toolkit.

Clause bank

Market data flow-down. Licensee shall not use Licensed Data in any Non-Display Application, or create Derived Data, except as expressly permitted in Schedule [X]. Licensee shall maintain a register mapping each Licensed Data feed to each application consuming it, shall update the register within [10] business days of any change, and shall provide it to Licensor on request. Licensee shall notify Licensor before deploying any new application consuming Licensed Data.

Model validation package. Vendor shall deliver, and maintain current, a Validation Package comprising: (a) a description of the model's methodology sufficient for an independent validator to assess conceptual soundness; (b) the complete list of input variables with definitions and sources; (c) reason code definitions mapped to model outputs, sufficient to support statutorily required adverse action notices; (d) performance and stability monitoring reports at [quarterly] intervals; (e) disparate impact testing results across [specified] segments; and (f) documentation of training data sources and the rights under which they were used. Vendor shall permit Customer's independent validator, under confidentiality, to inspect materials not included in the Validation Package where reasonably required for Customer's regulatory obligations.

Trade secret access control. Access to the Algorithm Repository is limited to individuals on the Access Schedule, maintained by the Chief Technology Officer and reviewed quarterly. Access is logged. No individual may hold access to more than [one] of the Restricted Components without written approval. All materials are marked "Confidential — Restricted". Departure procedures under [Exit Protocol] apply to every individual on the Access Schedule.

API terms — secondary use. Recipient shall use Data obtained through the Interface solely to provide the Authorised Services to the Consumer who authorised the access, and shall not: (a) use it for any other purpose, including model training, benchmarking, or product development; (b) retain it beyond [period] following termination of the Consumer's authorisation; (c) combine it with other data in a manner that would permit its use for a purpose prohibited by (a); or (d) transfer it to any third party other than an approved subprocessor listed at [reference].

Exchange licence termination continuity. On expiry or termination, Licensee may retain Licensed Data received before the effective date solely for regulatory record-keeping and for the defence of claims, and shall cease all other use. Models trained wholly or partly on Licensed Data may continue in production for [period], during which Licensee shall retrain or retire them. Licensee shall certify compliance within [30] days of the end of that period.

Network rule change allocation. Where a Network Rule change requires modification of the Services, Provider shall notify Customer within [10] business days of publication, provide an impact assessment within [30] days, and implement conforming changes at [its own cost / shared cost] before the Network's effective date. Neither party shall be in breach of this Agreement by reason of complying with a Network Rule.

Failures that recur

Filing a patent application on a trading method that will not issue, will be published, and will teach competitors what the firm does.

Licensing market data for display and building an algorithm on it, discovered in an audit with a multi-year lookback.

Assuming derived data ceases to be licensed because a calculation was applied to it.

Sharing a feed across group entities without affiliate permission.

Deploying a vendor model without a reason code mapping, then being unable to produce adverse action notices.

Using a proxy variable correlated with a protected characteristic and discovering it in a fair lending review.

Building on credential-based access and rebuilding when the bank closes it.

Treating an API terms document as documentation rather than as a contract.

Designing a payments product against a rulebook nobody read, discovered at certification.

Clearing a brand on the trademark register only, and finding a naming rule prohibits it.

Relying on 18 U.S.C. § 1030 for a data access claim that Van Buren forecloses.

And treating quantitative staff mobility as a human resources problem rather than as the sector's principal trade secret exposure.

Part seven: the portfolio decision

Every fintech company eventually asks whether to file at all, and the honest answer varies by what the invention is.

File when the invention is infrastructure. A latency-reducing network architecture, a specific data structure, a cryptographic construction, a hardware arrangement, or a fault tolerance mechanism has a genuine chance of issuing and a genuine chance of being detectable in a competitor's product.

File when the invention is customer-visible. A payment flow, an authentication interaction, or an interface behaviour can be observed from outside, which means a patent has leverage. An internal risk calculation cannot be observed, which means a patent on it is close to unenforceable.

File defensively when the sector is litigious, which payments is. A portfolio that deters assertion by creating counterclaim exposure has value that does not depend on ever suing anybody. See Who Is Really Suing You.

File when an acquirer will count. Portfolio size influences valuation in ways that are not always rational but are consistently real.

Do not file when the invention is a trading edge. Publication destroys it, issuance is unlikely, and detection is impossible. Keep it secret and build the access controls that make the secrecy defensible.

Do not file when the claim would have to be so narrow as to be designed around in an afternoon. A narrow claim on a specific implementation of an obvious idea is a maintenance fee, not an asset.

Publish defensively where neither route works. A defensive publication creates prior art against a competitor's later filing without disclosing more than the competitor could reverse-engineer anyway, and it costs a fraction of a patent application.

And review the portfolio annually against use. Financial technology moves quickly, and a portfolio accumulated over a decade will contain families covering products the company no longer offers and technologies the market has abandoned. Abandon them deliberately rather than paying maintenance fees by default. See the IP Audit Checklist.

Part eight: diligence and transactions

Fintech diligence has a predictable shape, and knowing it helps on both sides.

Eligibility exposure. Count the patents whose claims would not survive a motion under 35 U.S.C. § 101. In many portfolios this is a majority, and a buyer valuing the portfolio at a per-asset rate is overpaying. Test a sample properly rather than counting.

Data licence compliance. Obtain every market data and vendor data agreement. Map each feed to each application. Identify non-display use licensed for display, derived data outside the permitted definition, affiliate sharing without permission, and redistribution without consent. Quantify the back-payment exposure using the licensor's stated audit lookback. This is routinely the largest single contingent liability in a fintech acquisition and it is almost never surfaced by the seller.

Model governance. Obtain the model inventory, the validation packages, the monitoring reports, and the fair lending testing. A vendor model without a reason code mapping is a regulatory problem the buyer inherits.

Training data provenance. Identify every dataset used to train a deployed model and the rights under which it was obtained. Scraped data is the recurring finding, and the remedy — retraining — is expensive.

Trade secret hygiene. Test whether the algorithms the business depends on are actually protected: marked, access-controlled, covered by agreements, and supported by onboarding and exit records. A business whose entire value is an unprotected model is a business whose value walks out with three people.

Chain of title. The ordinary invention assignment analysis, which in fintech is complicated by heavy contractor use and offshore development. See the Employee Invention Checklist.

Open source. The component inventory and the licence obligations, with attention to copyleft in server-side software and to network-use provisions. See Copyleft and Consequences.

Network registrations and certifications, which may not transfer automatically on a change of control and which gate the business's ability to operate.

Brand clearance, including any regulatory naming constraint that a change of ownership might affect.

And open enforcement exposure: demand letters, assertion entity contacts, and any indemnity claims from customers. See the Patent Assertion Defense Toolkit.

Part nine: the market data audit, from the receiving end

Because audits are routine rather than exceptional, it is worth setting out how one actually runs.

The notice arrives from the exchange, the vendor, or an audit firm acting for them, citing the audit clause and proposing a scope and a timetable. The lookback is usually stated and is frequently longer than the firm expects.

The information request covers entitlement records, user lists, system architecture diagrams, application inventories, data flow documentation, and — increasingly — direct system access to verify counts.

The findings arrive in three categories. Entitlement undercounting, where more people or devices consumed display data than were licensed. Category misclassification, where a use licensed as display was in fact non-display. And scope excess, where derived data, redistribution, or affiliate use exceeded the grant.

Category misclassification is where the money is, because non-display fees are materially higher and because the misclassification usually persisted for the whole lookback period.

The response is documentary. Contemporaneous mapping records, written positions taken at the time, and any correspondence with the licensor about ambiguous categories. A firm that asked the question in writing three years ago and received an answer is in a completely different position from one that assumed.

Negotiation follows. Licensors settle, because the relationship continues and because litigating a licence interpretation is unattractive to both sides. The settlement usually combines a back payment, a prospective reclassification, and a compliance undertaking.

The forward terms matter more than the recovery, exactly as in any audit: a reclassification agreed prospectively removes the exposure permanently, while a payment for the past does not.

The controls that prevent recurrence are a live feed-to-application register, a gate in the product development process requiring a licence check before any new consumption, entitlement counts monitored rather than reconciled annually, and a documented escalation route for ambiguous categories. The parallel discipline for licensor-side audits is set out in the Royalty Audit and Licence Compliance Toolkit and the Royalty Audit Checklist.

Part ten: incidents, disclosure, and vendor risk

Financial technology carries an incident profile that shapes several intellectual property questions.

Security incidents reach trade secret assets as well as customer data. A breach that exfiltrates model code or trading logic is a trade secret loss, and the response should preserve the misappropriation claim as well as satisfy notification duties.

Notification obligations stack: state breach statutes, financial regulator expectations, network rules, contractual clocks, and — for public companies — disclosure obligations with their own materiality assessment and timetable. Build the matrix in advance. See Running a Data Breach Response and the Cybersecurity Governance and Disclosure Toolkit.

Privilege should be established early, with the forensic investigation conducted at counsel's direction, because the investigation report will be sought in every subsequent proceeding. See Protecting Privilege in an IP Matter.

Vendor concentration is the structural risk. Core processing, data feeds, cloud infrastructure, and model providers are frequently single-sourced, and the intellectual property terms in those agreements determine whether the business can survive a vendor failure. Escrow, portability, and continuity terms deserve the same attention here that they receive in regulated utility procurement.

Fourth-party risk is under-managed. The vendor's own vendors hold the data too, and the diligence rarely reaches them.

And the insurance position should be checked against the actual exposure, since cyber policies, technology errors and omissions cover, and intellectual property cover address different parts of the same incident. See the IP Insurance and Risk Transfer Toolkit.

Worked scenarios

A payments startup with a patentable idea. The founders believe their routing optimiser is novel and want to file. The eligibility analysis says the optimisation method itself is an abstract idea implemented on generic hardware and will not survive. But the same product contains a genuinely technical component: a message deduplication scheme that tolerates network partition without double-spending, with a specific data structure and a specific reconciliation protocol. The advice is to file on the second and keep the first as a trade secret, because the routing logic is invisible from outside and the deduplication scheme is not. Two years later a competitor's architecture reads on the deduplication claim, and the patent that was almost not filed is the one that matters.

A trading firm facing a data audit. The firm licensed a consolidated feed for display on forty terminals. Over four years it built an internal risk engine, a pricing service, and a compliance surveillance tool, all consuming the same feed automatically. None was licensed for non-display use. The audit lookback is three years and the non-display rate is a large multiple of the display rate. The firm's position rests entirely on whether anybody asked the question at the time — nobody did, and there is no correspondence. The settlement combines a substantial back payment with prospective reclassification. The control that would have prevented it costs one register and one gate in the development process.

A lender deploying a vendor model. The model improves approval rates materially and the vendor will not describe its methodology. The lender's obligations require specific reasons for adverse actions and a fair lending analysis. The negotiated answer is a validation package: reason code definitions mapped to outputs, an input variable list with definitions, quarterly performance and stability reporting, segment-level testing results, and a right for the lender's independent validator to inspect further material under confidentiality. The vendor resists, then accepts, because the alternative is that no regulated lender can buy the product. The lesson generalises: in this sector, a vendor's secrecy has to be compatible with its customer's obligations or the product is unsellable.

An aggregator losing credential access. The business was built on screen scraping using customer credentials. The banks close the route and offer a permissioned interface with narrower scope, rate limits, and secondary use prohibitions. The product depended on data fields the interface does not expose and on retention the terms forbid. The rebuild takes a year. The businesses that survived the transition were the ones that had negotiated interface access before they needed it, and that had never built a feature dependent on a field they had no durable right to.

A ninety-day programme

Weeks 1–2. Build the feed-to-application register: every data source, every application consuming it, and the licence category each consumption falls into. Expect to find non-display use licensed for display.

Weeks 3–4. Read every market data and vendor data agreement. Extract the definitions of display, non-display, derived data, redistribution, affiliate, and audit. Compare against the register. Quantify the exposure and decide whether to raise it proactively.

Weeks 5–6. Build the model inventory: every model in production, its owner, its inputs, its training data provenance, its validation status, its reason code mapping, and its monitoring cadence. Flag every model that decides something about a person and lacks an explainability path.

Weeks 7–8. Run the trade secret assessment. Identify the algorithms and models whose value depends on secrecy, apply marking and access segmentation, and align onboarding and exit procedures for the people who hold them.

Weeks 9–10. Review the patent portfolio against eligibility and detectability. Identify families to abandon, families to maintain, and inventions currently unfiled that should be filed or defensively published.

Weeks 11–12. Review interface and network terms: API agreements as contracts, applicable rulebook sections mapped to product features, and a change-monitoring process for unilateral rule amendments.

Throughout. Put legal in the product development path so that new data consumption, new model deployment, and new payment flows are reviewed before launch rather than at certification.

One paragraph to remember

In financial technology the patents mostly do not survive, the data is licensed rather than owned, the algorithms are regulated artefacts before they are trade secrets, and the network rulebooks are private law that no contract can override. Claim the infrastructure and keep the finance secret; map every feed to every application before an auditor does it for you; make the vendor's secrecy compatible with your regulatory obligations at procurement rather than after; and read the rulebook before designing the product, not at certification.

Two documents worth keeping current

The feed-to-application register. One row per consumption: data source, licence agreement reference, application name, owner, display or non-display classification, derived data assessment, redistribution status, entitlement count, and the date the classification was last reviewed. This single document answers most of an audit and prevents most of the exposure. It should be updated by the product development gate rather than by an annual exercise, because the classification changes when a product changes and nobody outside the team will notice.

The model inventory. One row per production model: name, owner, business purpose, decisions it informs, input variables, training data sources and rights, validation date and validator, reason code mapping status, monitoring cadence, last fair lending test, and vendor if third-party. A regulator, an auditor, and an acquirer will each ask for a version of this, and a business that maintains it answers in an afternoon while one that does not spends a month reconstructing it from memory and email.

Key Authorities at a Glance

Eligibility. 35 U.S.C. § 101; Alice Corp. v. CLS Bank International; Mayo Collaborative Services v. Prometheus Laboratories, Inc.; Bilski v. Kappos; In re Bilski; Enfish, LLC v. Microsoft Corp.; DDR Holdings, LLC v. Hotels.com, L.P.; Ultramercial, Inc. v. Hulu, LLC; buySAFE, Inc. v. Google, Inc..

Claiming and disclosure. 35 U.S.C. § 112 with Williamson v. Citrix Online, LLC; 35 U.S.C. § 102 and 35 U.S.C. § 103; 37 C.F.R. § 1.56.

Data. Feist Publications, Inc. v. Rural Telephone Service Co.; National Basketball Ass'n v. Motorola, Inc.; 17 U.S.C. § 103; 18 U.S.C. § 1030 with Van Buren v. United States and hiQ Labs, Inc. v. LinkedIn Corp..

Trade secret. 18 U.S.C. § 1836 and 18 U.S.C. § 1839; Rockwell Graphic Systems, Inc. v. DEV Industries, Inc.; PepsiCo, Inc. v. Redmond.

Software copyright and interfaces. 17 U.S.C. § 102; 17 U.S.C. § 107; Google LLC v. Oracle America, Inc.; Sega Enterprises Ltd. v. Accolade, Inc..

Trademark. 15 U.S.C. § 1051; 15 U.S.C. § 1052; 15 U.S.C. § 1114; 15 U.S.C. § 1125.

Consumer protection. 15 U.S.C. § 45 for unfair and deceptive practices; contract formation per Terms That Actually Bind. For statutory credit and financial data obligations generally, see Fair Credit Reporting and Equal Credit Opportunity.

| Authority | Governs | Practical consequence | | --- | --- | --- | | Alice | Eligibility | Claim the infrastructure, not the finance | | Enfish | Technical improvement | The specification must state one | | DDR Holdings | Internet-specific solutions | A narrow but real survival route | | 35 U.S.C. § 112 | Functional claiming | Result language invites means-plus-function | | Feist | Facts | Market data is contractual, not owned | | Exchange licences | Display and non-display | Audit exposure with multi-year lookback | | 18 U.S.C. § 1836 | Trade secrets | Where the algorithms actually live | | Rockwell | Reasonable measures | Access segmentation and marking | | Van Buren | Computer access | Contract claims do more work | | Google v. Oracle | Interface reimplementation | Supports interoperability work | | 15 U.S.C. § 1052 | Registrability | Descriptiveness is the usual bar | | Network rulebooks | Payments participation | Private law, unilaterally amendable |