Financial Technology IP Checklist: Eligibility Screening, Market Data Terms, Model and Algorithm Governance, Open Banking Interfaces, and Customer Data Rights

By Casey Scott McKay · 2024-08-26

This checklist audits a financial technology business in the order the exposure actually sits, which is not the order the client expects. It begins with the market data entitlement inventory because that is the item with a quantified downside and a fixed deliverable, and because no firm can defend a vendor audit without one. It then screens disclosures against the eligibility framework, enumerates the secrets and reconciles access controls with the model documentation regulators require, and reviews the six vendor clauses where the sector's assertion exposure is created. Later phases cover open banking obligations, the transaction data use matrix, partnership and sponsorship terms, code registration and contractor assignments, and the standing defensive file. Gate items mark where work should stop.

IP and Technology > Information Technology | Checklist | Published 26 August 2024 - Updated 15 May 2026 | Casey Scott McKay - marksy.us

Summary. This checklist audits a financial technology business in the order the exposure sits rather than the order the client expects. It begins with the market data entitlement inventory, the item with a quantified downside and a fixed deliverable. It then screens disclosures against the eligibility framework, enumerates secrets and reconciles access controls with the model documentation regulators require, and reviews the six vendor clauses where assertion exposure is created. Later phases cover open banking obligations, the transaction data use matrix, partnership terms, code registration, and the standing defensive file. Gate items mark where work should stop.

Keywords: fintech checklist · entitlement inventory · non-display use · derived data · eligibility screening · technical improvement claims · model governance · secret enumeration · vendor indemnity review · open banking compliance · transaction data basis · partnership terms · code registration · assertion defence · contractor assignments

How to use this checklist

| Phase | What it produces | Who runs it | Gate | |---|---|---|---| | 1. Entitlements | A feed-to-system inventory | Counsel and engineering | Generated, not interviewed | | 2. Eligibility | A screening memorandum per disclosure | Counsel and patent counsel | Reasoning recorded, including refusals | | 3. Secrets | A register and an access matrix | Counsel and model risk | Compliance documents included | | 4. Vendors | A six-clause position paper | Counsel and procurement | Applied at renewal | | 5. Interfaces | A compliance note per regime | Counsel and regulatory | Standards commitments identified | | 6. Data uses | A use matrix with bases | Counsel and product | Product gate installed | | 7. Partnerships | A term sheet by contribution | Counsel | Permission and product separated | | 8. Registration | A quarterly schedule | Counsel | Deposit approach settled | | 9. Defence | A standing file | Counsel | Vendor positions mapped | | 10. Digital assets | An addendum, if applicable | Counsel | Not a separate programme |

The matter. A payments and analytics business consuming six market data feeds, running credit and fraud models documented extensively for model risk, operating on a core platform licensed from a vendor whose indemnity nobody has read, partnered with a sponsor institution whose agreement assigns the technology, and holding eighteen invention disclosures nobody has screened.

Phase 1. Build the market data entitlement inventory

[ ] Start here, before anything else, because this is the only item with a quantified downside and a fixed deliverable.
[ ] List every feed — exchange, vendor, aggregator, redistributor — with the governing agreement and its date.
[ ] Generate the system mapping from configuration, not from interviews, since interviews miss connections nobody remembers making.
[ ] Classify each consumption as display or non-display. Data shown to a human is licensed differently from data consumed by an algorithm, non-display fees are frequently larger, and this is where most audit findings originate.
[ ] Count users, devices, or enterprise units against the agreement's own counting rules rather than against assumptions.
[ ] Identify derived outputs — indices, signals, risk metrics, benchmarks, analytics — and where each is distributed.
[ ] Identify redistribution, including to affiliates, which frequently counts as external.
[ ] Separate historic and research entitlements, since terms differ from production.
[ ] Find departed users still entitled, a recurring finding and a trivial fix.
[ ] Re-run quarterly against actual connections, since the gap between the register and the network is where findings live.
[ ] [Gate] No renewal is negotiated and no audit is answered without the inventory.

Phase 2. Screen disclosures against eligibility

[ ] Sort into three buckets: technical architecture, hardware-entangled, and financial concepts on generic computers. Only the first two are worth filing domestically.
[ ] Test honestly against the framework in Alice Corp. v. CLS Bank International. A better way to price risk, using a computer, will not survive.
[ ] Use a four-question form: what technical problem, what did the prior approach do, what measurable improvement, and where in the system does it occur. A disclosure that cannot answer the third is not a candidate.
[ ] Write the specification to carry a technical narrative, since a specification describing a business advantage supplies nothing to hold.
[ ] Watch the prosecution record, because arguments made to overcome an eligibility rejection become the record for claim construction.
[ ] Run the screen twice for international filing, once against the abstract-idea framework and once against a technical-character test, and expect different answers.
[ ] Check functional claims against 35 U.S.C. § 112, Amgen Inc. v. Sanofi, and Nautilus, Inc. v. Biosig Instruments, Inc..
[ ] Record decisions not to file, since an allocation of budget documented as a choice is a very different thing in hindsight from an absence nobody chose.
[ ] [Gate] No financial-method application is filed without a written explanation of why it will issue.

Phase 3. Enumerate secrets and fix the access controls

[ ] Enumerate at artefact level: this model file, these parameter sets, this feature definition, this tuning log. "Our pricing methodology" is not enumeration and will not support identification in litigation.
[ ] Mark and segregate model artefacts from general engineering documentation.
[ ] Confront the conflict. Model risk frameworks, validation reports, internal audit files, and supervisory submissions all describe the model in detail and circulate to people nobody has restricted.
[ ] Restrict compliance documentation too, which is achievable without obstructing the compliance function once the model risk team is told why.
[ ] Check training data provenance, since a model trained on licensed market data inherits those terms.
[ ] Run onboarding and exit properly, since quantitative staff are mobile and covenants are narrowing.
[ ] Record what a departing person could reach, because that record is the claim.
[ ] Confirm reasonable measures are satisfied under 18 U.S.C. § 1839 by process rather than by intention.
[ ] [Gate] A model stored on an open share is not a protected secret, whatever the policy says.

Phase 4. Review the six vendor clauses

[ ] Indemnity scope and cap. A cap at fees paid against a damages theory based on transaction volume is not protection.
[ ] Combination and modification exclusions, since an integrated core platform is exactly the configuration most exclusions carve out.
[ ] Control of defence and settlement, because a vendor settling conveniently for itself may leave the institution exposed.
[ ] Source escrow with a build environment, with release on insolvency and sustained support failure.
[ ] Data and training rights, including whether the vendor may train on the institution's data and what survives termination — where the honest answer about a trained model is that nothing unwinds.
[ ] Regulatory status representations where the product creates one, rather than a general compliance clause.
[ ] Obtain a machine-readable software bill of materials, since financial infrastructure is substantially open source.
[ ] Set breach notification periods you can meet in your own downstream and supervisory obligations.
[ ] Apply the position paper at renewal rather than by amendment, since partners accept renewals and resist amendments.
[ ] [Gate] If only two positions can be won, take the cap carve-outs and the training rights.

Phase 5. Establish the open banking position

[ ] Confirm which regime applies to which products and segments, since coverage varies.
[ ] Identify standards participation obligations, since contributing to an interface standard may create declared-essential patents with licensing commitments.
[ ] Recognise that the interface is a regulated artefact, which makes questions of the kind raised in Google LLC v. Oracle America, Inc. largely academic where the specification is mandated.
[ ] Set a defensible screen-scraping position, since access restrictions raise questions under 18 U.S.C. § 1030 as narrowed in Van Buren v. United States.
[ ] Document data quality and availability, because complaints about sparse fields, rate limits, and downtime go to regulators rather than to courts.
[ ] Allocate downstream responsibility where a third party misuses data obtained through the interface.
[ ] Consider the reciprocal position, since sharing without consuming is a worse competitive place than doing both.
[ ] [Gate] Minimal compliance is a supervisory matter, not an engineering decision.

Phase 6. Build the transaction data use matrix

[ ] List the data categories: transaction records, merchant data, device and session data, location, and derived behavioural attributes.
[ ] State a basis for each use against three overlapping systems — the sector-specific confidentiality regime, the comprehensive privacy statutes, and the network operating rules.
[ ] Screen for consumer reporting characterisation under 15 U.S.C. § 1681a, since information furnished for credit, employment, insurance, or housing decisions brings the procedural apparatus of 15 U.S.C. § 1681b and 15 U.S.C. § 1681m.
[ ] Test the de-identification standard for any aggregate product, since card-level spending aggregates have repeatedly proved re-identifiable.
[ ] Check representations to purchasers, since that is where liability attaches under 15 U.S.C. § 45.
[ ] Address merchant rights in transaction records, which processor terms allocate more aggressively than merchants notice.
[ ] Map network rule constraints, which are contractual, enforced by fines and access, and frequently stricter than the statutes.
[ ] Address cross-border transfer, which is inherent in a payments network.
[ ] Install a product gate: any new use of customer transaction data goes to legal before it ships.
[ ] [Gate] A cell in the matrix with no basis is an unapproved use.

Phase 7. Fix the partnership and sponsorship terms

[ ] Identify what each side genuinely cannot obtain elsewhere. The institution supplies permission; the partner supplies product.
[ ] Resist ownership demanded for continuity reasons, since the legitimate need is a continuity licence on defined triggers rather than an assignment.
[ ] Settle customer ownership expressly — whose customer, who may market, what happens on termination.
[ ] Address data flows in both directions, since the institution gains transaction visibility and the partner gains outcome data.
[ ] Accept oversight obligations, since the institution remains accountable to its supervisor for the partner's conduct.
[ ] Negotiate exit asymmetrically, since a partner losing its sponsor loses its ability to operate.
[ ] Address change of control, since acquisition of the partner by the institution's competitor is the event the agreement should anticipate.
[ ] [Gate] Do not spend goodwill resisting oversight; spend it on ownership, customers, and exit.

Phase 8. Register the code and protect the brand

[ ] Register in quarterly batches, since 17 U.S.C. § 412 conditions statutory damages and fees on timely registration and 17 U.S.C. § 411 conditions suit.
[ ] Settle the deposit approach, using redaction options rather than depositing the model.
[ ] Take contractor assignments under 17 U.S.C. § 204, since a purchase order transfers nothing and 17 U.S.C. § 201 leaves ownership with the author.
[ ] Clear product names against pre-clearance regimes as well as the register.
[ ] Build an impersonation takedown pipeline, since phishing domains and fraudulent applications are the dominant enforcement problem and are addressed operationally rather than by litigation, under 15 U.S.C. § 1114 and 15 U.S.C. § 1125.
[ ] Address embedded finance attribution, where the customer-facing brand belongs to the technology partner.
[ ] [Gate] Contractor assignments are obtainable only while the contractors are contactable.

Phase 9. Assemble the defensive file

[ ] Map every vendor's indemnity position, with cap, carve-outs, and control provisions, maintained by whoever handles renewals.
[ ] Record every known assertion against a peer, with the outcome.
[ ] Collect invalidity rulings obtained by anyone in the sector, which is the cheapest research available.
[ ] Assess eligibility first on any incoming assertion, since a financial-method patent is more vulnerable under 35 U.S.C. § 101 than on prior art and the motion can precede claim construction.
[ ] Model damages against transaction volume, since that is the plaintiff's theory and the apportionment fight under 35 U.S.C. § 284 is the case.
[ ] Consider post-grant proceedings, noting the covered-business-method route has lapsed.
[ ] Preserve immediately, since source code, model documentation, and design history are the discovery targets and FRCP 37 obligations attach on reasonable anticipation.
[ ] Coordinate where the campaign is serial, subject to competition advice on information sharing.
[ ] [Gate] Tender to the vendor before defending, and preserve the position on the cap.

Phase 10. The digital asset addendum

[ ] Treat it as an addendum, not a programme, since the analysis above applies with almost no adjustment.
[ ] Recognise the protocol is open source, so the advantage lies in network, liquidity, integrations, and brand.
[ ] Read the token terms, since what a holder receives is whatever they say.
[ ] Prioritise impersonation enforcement, since names are used to defraud and speed is the only effective remedy.
[ ] File on custody, key management, settlement, and scaling, which are genuinely technical and repay their cost.
[ ] Note that forks are an unresolved rights question, where a codebase diverges and both branches claim a name.
[ ] Do not build a strategy on a classification assumption, which is the least stable variable in the field.

The regulatory technology layer

[ ] Identify vendor-supplied surveillance and monitoring systems — trade surveillance, communications monitoring, transaction monitoring — and record what the institution configured, which is its genuine contribution and is documented nowhere but the system.
[ ] Treat alert thresholds as policy expressed as parameters, since where a threshold sits determines what a compliance team can investigate and regulators increasingly ask to see the reasoning.
[ ] Recognise that model risk documentation describes the secret, and control access to validation reports accordingly.
[ ] Record the interpretation encoded in regulatory reporting logic, which is proprietary, valuable, and shared with auditors and supervisors.
[ ] Assess vendor concentration, since a small number of suppliers serve most of the market and a failure is a supervisory event as well as a commercial one.
[ ] Prepare for supervisory examination of the code, since where a regulator asks how a decision was reached the answer is in software.
[ ] Note that false positive reduction is where the genuine innovation is, and that almost none of it is patentable.

Where fintech positions fail

[ ] The filings came first, and three years later the portfolio is mostly refused and the entitlement inventory still does not exist.
[ ] Nobody read the market data agreements until the audit letter arrived, at which point the position is whatever the vendor's connection logs say.
[ ] Non-display use was licensed as display, the single most common finding, invisible until systems are mapped to feeds.
[ ] Model documentation defeated the secrecy claim, because compliance did what it had to and nobody restricted circulation.
[ ] The vendor indemnity was never read: capped at fees paid, excluding combinations, with the vendor controlling the defence.
[ ] Transaction data uses accumulated without a basis, one product feature at a time.
[ ] The sponsorship agreement assigned the technology, because a continuity request was treated as reasonable without distinguishing a licence from an assignment.
[ ] Contractor code was never assigned, discovered in diligence and fixable only while the contractors remain contactable.
[ ] Nobody knew which vendor was responsible when the assertion arrived, so the institution defended and paid.
[ ] Eligibility arguments made in prosecution narrowed the claims fatally, and nobody read the file wrapper before asserting.

The documents an audit should produce on request

[ ] The entitlement inventory, current, generated, with usage categories per feed-and-system pair.
[ ] A screening memorandum per disclosure, including refusals, with dates and reasoning.
[ ] The secret register, at artefact level, with the access matrix covering compliance documentation.
[ ] The vendor position paper and a mapping of which contracts reflect it.
[ ] The open banking compliance note per regime, with standards commitments identified.
[ ] The transaction data use matrix, with a basis in every populated cell.
[ ] The partnership term sheets, distinguishing permission from product.
[ ] The registration schedule with the last four quarters evidenced.
[ ] The contractor assignment file, complete or with the gaps listed.
[ ] The defensive file, with vendor positions, peer assertions, and known invalidity outcomes.
[ ] The product gate record, showing new data uses reviewed before shipping.
[ ] The board allocation memorandum, dated, explaining why the budget went where it did.

If a business can produce all twelve, the programme is functioning. If it can produce the inventory, the screening memoranda, and the secret register, it is on the way. If it can produce only a patent docket, it has been solving the wrong problem.

Variants by client type

[ ] The early-stage startup. No market data, no model risk function, no vendor estate. Three priorities only: contractor assignments, the sponsor agreement, and a decision not to spend on financial-method filings that an investor question would otherwise prompt. Phase 1 becomes urgent overnight the day the firm licenses its first feed.
[ ] The incumbent institution. Extensive vendor estate, heavy market data consumption, a mature model risk function producing the documentation that defeats a secrecy claim, and disclosures nobody screens. Priorities are Phases 1, 3, and 4 — and the characteristic problem is that these sit in three functions that do not speak, so the highest-value structural change is one person across all three.
[ ] The technology vendor selling into institutions. The mirror image: it grants the indemnities, holds the customers' data, and answers the questionnaires. Priorities are the bill of materials, customer data and training terms, a realistic indemnity it can honour, and continuity arrangements that satisfy supervisors without surrendering source.
[ ] The trading firm. Market data dominates everything. Phase 1 is the engagement, Phase 3 protects the models, and Phases 5 through 7 may not apply at all.
[ ] The unregulated participant operating through a partner. Exposure is contractual and reputational rather than supervisory, but the partner's supervisor reaches it through the partner, and the oversight obligations in the partnership agreement are not negotiable in substance.

First ten days, for a practitioner with other work

[ ] Day one: install the product gate. One email: any new use of customer transaction data goes to legal before it ships. An hour, and it stops the problem growing.
[ ] Day two: ask engineering for the feed-to-system list. Not procurement, not the data team's spreadsheet — the actual configuration. This is the skeleton of Phase 1.
[ ] Days three to four: read the largest vendor contract's indemnity. Cap, exclusions, control of defence. It determines who pays if an assertion arrives tomorrow.
[ ] Day five: ask where the models live and who can open the validation reports. The answer is usually "a shared drive" and "everyone."
[ ] Days six to seven: pull the invention disclosure list and sort it into three buckets. Most firms discover the ratio is worse than they assumed, which makes the budget conversation easier.
[ ] Day eight: check whether contractor code has assignments. Fixable now, impossible later.
[ ] Day nine: check the sponsor or partnership agreement's ownership clause, if the client has one.
[ ] Day ten: write the one-page brief — what was found, what was fixed, what needs budget, and why the inventory comes before the filings — and send it before anyone else describes the position.

What good looks like

[ ] The entitlement inventory is generated and current, answerable in a day.
[ ] Disclosures are screened with recorded reasoning, including refusals.
[ ] Secrets are enumerated at artefact level and access controls reach the validation documentation.
[ ] Six vendor clauses are negotiated everywhere, from one paper, at renewal.
[ ] Interface obligations and standards commitments are documented per regime.
[ ] Every transaction data use has a basis, and a product gate holds the line.
[ ] Partnership terms separate permission from product.
[ ] Code is registered quarterly and contractor assignments are current.

Firms with those eight defend an audit from a file and answer diligence in a week. Firms without them learn, in the order that costs most, that the audit is unanswerable, the diligence is a discount, and the departure is unprovable.

Three audits worked through

A trading firm's first entitlement inventory. The engagement begins with an engineering request rather than a legal one: produce every market data connection and the application consuming it. Six weeks later the picture is that four feeds licensed for display are consumed by automated strategies, one vendor's data feeds an index published to clients with no derived data right, an affiliate in another jurisdiction reaches the internal terminal pool, and eleven entitlements belong to people who left. The remediation is a voluntary disclosure to two vendors, a renegotiation with the third, and a process tying entitlement to system deployment rather than to procurement. Settlements are negotiable on multiplier and look-back and not on whether the usage occurred, because the vendor can see the connections. The firm's next three renewals are conducted from knowledge rather than hope.

A payments startup preparing for a financing. Diligence asks three questions the founders have not prepared for. Contractor code from the first eighteen months was never assigned, fixable while the contractors are contactable and impossible afterwards. The sponsor agreement assigns the technology outright, signed because a continuity request looked reasonable, materially reducing what an acquirer is buying, and renegotiable at renewal at a cost worth paying. And the fraud model was trained partly on data whose licence prohibits derived use, requiring either an amendment or a retraining plan. The patent question — eighteen disclosures, of which two are technical architecture — is answered in an afternoon and is the least important item on the list.

An incumbent facing a serial assertion. The plaintiff has sued six peers. The first step is the indemnity in the core platform contract, which covers the accused function, caps at fees paid, and gives the vendor control of the defence — so the institution tenders, reserves on the cap, and runs a parallel eligibility analysis. The patent claims transaction routing based on risk scoring, squarely the financial method that fails at step two. The motion is filed before claim construction, the peers' public briefing is obtained, and the damages model is stress-tested against transaction volume so settlement authority is set on the plaintiff's theory rather than the defendant's.

The conversations that make the programme happen

[ ] Engineering resents the eligibility screen. Explain the position once, with two refused financial-method claims and one allowed architectural claim, and disclosure quality improves permanently. Engineers write better disclosures when they know what the office is looking for.
[ ] Trading and quantitative teams regard access controls as friction. The argument that lands is the departure scenario rather than the compliance one: the programme is what lets the firm act when a team leaves.
[ ] Compliance and model risk are producing the documentation that defeats the secrecy claim, and they are doing so because they must. Do not ask them to document less; ask them to restrict circulation, which they accept once the reason is given.
[ ] Procurement measures itself on cycle time. A one-page position paper with six clauses and a fallback for each reduces the marginal cost per contract to nothing.
[ ] Market data operations already knows most of the picture and has never been asked to write it down. Give them the authority and the first inventory arrives faster and more accurately than any external exercise.
[ ] Product adds data uses without asking. The one-line gate is the highest-yield hour available.
[ ] The board wants to know about patents. Answer with a dated allocation memorandum: what was filed, why the rest went elsewhere, and what that bought.

Timelines

[ ] Entitlement inventory: four to eight weeks, mostly engineering time, and it funds the rest of the programme by finding something.
[ ] Screening process: ten hours to establish, then a fortnightly review and a recorded decision.
[ ] Secrecy programme: six to twelve weeks, where the hard part is the model risk conversation rather than the drafting.
[ ] Vendor renegotiation: two to three years, because it happens at renewal, and the position paper is written once.
[ ] Data use matrix: three to four weeks, then maintained by the product gate.
[ ] Partnership term sheet: drafted once, saving a fortnight per transaction thereafter.
[ ] Code registration: half a day per quarter once the deposit approach is settled.
[ ] Who does it. One privacy-and-technology-literate lawyer with access to engineering can run all of it. The failure mode is splitting it between a patent counsel who never sees the data agreements and a commercial lawyer who never sees the disclosures.

Cross-border adjustments

[ ] Eligibility differs fundamentally. Several major jurisdictions apply a technical-character requirement rather than the abstract-idea framework, so the same application may be allowable abroad and refused at home. Run the screen twice and expect different answers.
[ ] Market data licences are territorial and per-venue, with a dozen agreements using incompatible definitions of display, non-display, and derived use. Classify internally to the strictest definition in the estate.
[ ] Data protection regimes diverge on financial information, automated decision-making, and transfer, and a model making credit decisions may face explanation and human-review obligations in one market and none in another.
[ ] Open banking mandates differ in scope, standard, and enforcement, so an institution across several regimes maintains several interfaces and several supervisory relationships.
[ ] Produce a two-page matrix: global standards, local instruments, and genuinely divergent analyses. For this sector the third column is longer than usual and eligibility sits at the top of it.

A closing note on sequencing

The difficulty of auditing this sector is not doctrinal. It is that the client's engineering organisation is sophisticated, its regulatory function is well resourced, and its intellectual property instincts are borrowed from an industry whose subject matter is patentable.

The result is a persistent misallocation: money on filings that will not issue, attention on a portfolio that deters nobody who matters, and none at all on the licences governing the firm's most critical inputs.

Correcting it does not require winning an argument about doctrine. It requires producing the entitlement inventory, showing what it found, and letting the finding make the case. The inventory always finds something, the something is always expensive, and the programme is funded thereafter without further persuasion.

Start there, and work the phases in the order given.

The entitlement inventory in detail

Because this is the phase with the quantified downside, it deserves specification rather than description.

[ ] Row granularity is the feed-and-system pair, not the agreement, because that is the unit an audit tests. A single agreement covering six systems produces six rows.
[ ] Columns: feed name, vendor, agreement reference and date, consuming system, environment (production, development, disaster recovery), usage category, entitled user count, derived outputs, distribution destinations, and named owner.
[ ] Generate the consuming-system column from configuration — connection strings, firewall rules, network egress, and scheduler definitions — rather than from a survey, since surveys miss connections established quietly.
[ ] Include development and test environments, which frequently consume production feeds under agreements that do not contemplate it.
[ ] Include disaster recovery, where duplicate consumption is common and separately chargeable.
[ ] Record the definition each agreement uses for display, non-display, and derived data, since they differ and the internal classification must map to each.
[ ] Flag every output that leaves the firm, including client reports, marketing materials, regulatory filings, and research notes, since redistribution is separately licensed.
[ ] Reconcile the user count to the identity system rather than to the vendor's terminal list, since the two diverge and the vendor's number is the one that will be used.
[ ] Record the date of each reconciliation, because a register with a date is evidence of a process and one without is a spreadsheet.
[ ] Tie entitlement provisioning to system deployment, so that a new consuming system cannot go live without an entitlement decision. This is the forward fix and it is what stops the problem recurring.
[ ] [Gate] The inventory is not complete until someone can answer, without preparation, which systems consume which feeds in which category.

The eligibility screen in detail

[ ] The four questions on the disclosure form: what technical problem does this solve, what did the previous technical approach do, what measurable improvement results, and where in the system does the improvement occur.
[ ] A disclosure that answers only in business terms — faster approval, better conversion, lower loss rates — is describing an outcome rather than a mechanism, and is not a filing candidate however valuable the outcome.
[ ] A disclosure that answers in system terms — fewer round trips, lower memory footprint, tolerance of node failure, cryptographic guarantee — is describing a mechanism and may be.
[ ] Bucket A: technical architecture. Latency, throughput, fault tolerance, memory, consensus, cryptography, key management, data structures with technical effect. File.
[ ] Bucket B: hardware-entangled. Terminals, readers, secure elements, specialised acceleration. File, and consider design filings alongside.
[ ] Bucket C: financial concepts on generic computers. Pricing, scoring, routing by risk, underwriting logic, matching by economic criteria. Do not file domestically; consider whether a technical-character jurisdiction takes a different view.
[ ] Record the bucket and the reasoning for every disclosure, including every refusal, since the record is what turns an absence of filings into a documented allocation.
[ ] Review the bucket assignment annually for anything still commercially significant, since claim drafting practice and examination approach both move.
[ ] [Gate] No application in Bucket C is filed without a written explanation of the technical narrative that will carry it.
[ ] Keep the refusals where the next practitioner will find them, since the question "why did we never file on this" recurs at every change of counsel and an undocumented absence looks like neglect.

Key Authorities at a Glance

| Authority | Phase | |---|---| | 35 U.S.C. § 101 | 2, 9 — the screen and the best defence | | Alice Corp. v. CLS Bank | 2 — the governing framework | | Bilski v. Kappos | 2 — hedging as an abstract idea | | Mayo v. Prometheus | 2 — the two-step structure | | Diamond v. Diehr | 2 — what a technical improvement looks like | | 35 U.S.C. § 112 | 2 — functional claiming limits | | Amgen v. Sanofi | 2 — enabling a claimed class | | Nautilus v. Biosig | 2 — indefiniteness | | 35 U.S.C. § 103 | 2 — obviousness over known components | | KSR v. Teleflex | 2 — combination obviousness | | 35 U.S.C. § 271 | 9 — divided infringement across the chain | | 35 U.S.C. § 284 | 9 — apportionment against transaction revenue | | 35 U.S.C. § 285 | 9 — fee shifting | | Octane Fitness v. ICON | 9 — the exceptional-case standard | | eBay v. MercExchange | 9 — injunctions against a live system | | Microsoft v. i4i | 9 — why eligibility is preferred | | 17 U.S.C. § 102 | 8 — code protected, method not | | 17 U.S.C. § 106 | 8 — the rights asserted | | 17 U.S.C. § 201 | 8 — contractor ownership default | | 17 U.S.C. § 204 | 8 — the signed assignment | | 17 U.S.C. § 411 | 8 — registration before suit | | 17 U.S.C. § 412 | 8 — timely registration and remedies | | Google LLC v. Oracle America | 5 — interfaces and reimplementation | | Feist v. Rural Telephone | 6 — transaction compilations are thin | | 18 U.S.C. § 1839 | 3 — reasonable measures over models | | 18 U.S.C. § 1836 | 3 — the federal claim on departure | | 18 U.S.C. § 1831 | 3 — espionage exposure in infrastructure | | 18 U.S.C. § 1030 | 5 — scraping and credential access | | Van Buren v. United States | 5 — authorised access, narrowed | | 15 U.S.C. § 1681a | 6 — consumer report characterisation | | 15 U.S.C. § 1681b | 6 — the procedural consequences | | 15 U.S.C. § 1681m | 6 — adverse action sequence | | 15 U.S.C. § 45 | 6 — representations to purchasers | | 15 U.S.C. § 1114 | 8 — impersonation and phishing marks | | 15 U.S.C. § 1125 | 8 — false association | | 16 CFR 314 | 4 — safeguards and vendor diligence | | 17 CFR 248 | 6 — privacy rules for regulated entities | | FRCP 26 | 9 — source code and model discovery | | FRCP 37 | 9 — preservation on anticipation |

Search the underlying materials directly for market data audit non-display finding, section 101 financial method rejection, model validation documentation trade secret, sponsor bank agreement intellectual property, and payment processor indemnity cap.