Consumer Finance · Cards · Case study
Check whether two fee rates are live for the same merchant, without laying the contracts out one by one
What it gets youLink one merchant's layered master contract and special clauses as Merchant, Contract, and Fee·Term entities, and get differing fee rates live on the same transaction, or settlement cycles that contradict each other, flagged as conflict candidates.
A new contract lands on the desk. It's a side agreement lowering a certain merchant's promotional fee rate for just one quarter. The reviewer pauses. Didn't this merchant separately sign a special clause last year changing their settlement cycle? They aren't sure how the fee terms were sorted out back then.
In the document store, several contracts bearing the same merchant's name are scattered about. The master contract, an agreement on a change of business type, preferential terms by volume, a promotional special clause. Each was drafted at a different time, by a different person, in slightly different wording and table format. To check whether one new term collides with something somewhere in this pile, you have to rely on a person's memory and patience.
First, something to make clear. This piece is not an actual customer case. It's a hypothetical scenario asking whether a card company, within consumer finance (the financial business of lending to individuals and firms or handling their payments on their behalf), might solve this problem this way. There's no deployment result and no figures yet.
Contracts pile up in layers on one merchant
A card company signs contracts with countless merchants. Yet it's surprisingly rare for a single merchant to have just one contract. On top of the master contract signed at first enrollment, new terms get layered on when the business type changes, preferential fees get added as transaction volume grows, and promotional special clauses get tacked on in certain seasons. Here's the material piled up in front of that one merchant.
- The master contract. Signed at first enrollment, and every other term is layered on top of it
- The business-type change agreement. New terms were added when the merchant's line of business changed
- Preferential terms by volume. A preferential fee was attached as transaction volume grew
- The promotional special clause. Tacked on separately each season. This new side agreement belongs here too
- The terms inside each contract. Settlement cycle, fee rate, and applicable period are written with a slightly different face in every contract
- The format. A good many lie dormant as scans or PDFs, and the fee rate sits inside a table rather than the body text
- The drafting history. Each was written at a different time, by a different person, in slightly different wording and table format
The problem is that these terms aren't independent of one another. When you add a new contract or amend an existing term, you have to check that it doesn't collide with another contract for the same merchant. It's a problem if two fee rates are live for the same transaction, or if one side records monthly settlement while another agreement sets it weekly, or if a special clause directly contradicts the master contract — and the conflict only surfaces later, at the settlement stage.
It ultimately comes down to the reviewer's memory
The procedure today is simple. When a new item comes in, the reviewer recalls in their head the existing contracts related to that merchant, digs through the document store, and lays them out one by one to compare. When there are only a few contracts, this works. But once the contracts grow vast, recalling every related contract without omission runs straight into human limits.
Trying to fill the gap with search hits a wall too. The question "which contracts could conflict with this one?" can't be caught by simple keyword search. A conflict isn't visible where words overlap — it only appears once you follow the relationships among merchant, contract, and fee terms. On top of that, even for the same condition, the wording differs from contract to contract and the table formats vary, so matching text as-is makes it hard to even tell whether two things are the same concept.
Turn the pile of contracts into a web of relationships
What you do in the setup stage is turn the pile of contracts into a connected web of relationships. Think of it as organizing the core objects with an ontology (the skeleton of knowledge that explicitly defines concepts and the relationships between them). The order is: read the scans, pull the core objects out as entities, then fold the wording variants into one.
Getting the merchant contracts in
Feed the contracts to "Extract sources" (⌘⇧I)
Contracts lying dormant as scans or PDFs are read with OCR (the technology that converts scanned images into characters a computer can read) and moved over with not just the body text but the structure of the tables holding the fee rates preserved. Because when a table collapses the terms collapse with it, keeping the table structure intact is especially important.
Declare canonical predicates and their variants in "Domain vocabulary"
In the "Domain vocabulary" panel in the left rail, declare canonical predicates and their variants. If "monthly settlement" and "settled once each month" mean the same thing, they fold into one at extraction time and merge into the same point inside the system. Even when the wording differs from contract to contract, the same concept becomes a single node.
Activity center's "Build this workspace's knowledge graph?" → "Build"
Merchant, Contract, and Fee·Term each get pulled out as entities and linked by relationships like "a merchant has many contracts" and "a contract has many fee terms." The original contract files stay right where they are, beside the knowledge graph (a map where concepts are linked by relationships) this builds.
Skim the results in the "Entity table"
This is where you check that merchants, contracts, and fee terms came out organized the way you intended. It's also where you see with your own eyes how many layers of contracts had piled up on this one merchant.
Ask which contracts could conflict
"@promotional-fee-side-agreement Show me every contract signed with this merchant."
→ Starting from the merchant entity and following the lines of relationship,
the result unfolds on one screen.
The master contract, the business-type change agreement, preferential terms
by volume, and the promotional special clause all come along.
Because it follows relationships instead of tossing out keywords,
contracts the reviewer failed to recall get pulled out too.
"Are there any terms that could conflict with this side agreement's fee rate?"
→ Where differing fee rates are live for the same merchant and the same
transaction, and where a special clause diverges from the master contract,
are flagged as conflict candidates by rules.
Each row carries the sentence stating the term and the contract it came from.
"How is this merchant's settlement cycle written in each contract?"
→ "monthly settlement" and "settled once each month" have merged into one point,
and if one is set monthly while another agreement is set weekly,
they're shown side by side as contradictory settlement cycles.The reason this answers is that the contracts are stored as entities and relationships rather than as text. Start from one merchant, follow the "has contract" and "has fee term" lines, and every contract and term connected to that merchant unfolds on one screen. Nobody has to recall the related contracts without omission.
Every fact carries which contract said it. Hover a connection chip and the source sentence behind the fact is quoted, captioned like "{note} · line {n}", and "In your words" on the entity page shows the wording actually written in the contract. Even when the wording is normalized and merged into one, what the original contract said stays intact. Instead of cross-checking every contract exhaustively from the start, the reviewer opens the spots the system points to, verifies them, and judges.
What could change
| Before | Now |
|---|---|
| The reviewer recalls the related contracts in their head, digs through the document store, and lays them out one by one to compare | Start from one merchant, follow the lines of relationship, and every connected contract and term unfolds on one screen |
| "Which contracts could conflict?" can't be caught by keyword search | Because it follows relationships, even contracts a person failed to recall get pulled out along with the rest |
| Wording and table formats differ from contract to contract, so it's hard to even tell whether two things are the same concept | Declare the variants in "Domain vocabulary" and "monthly settlement" and "settled once each month" merge into the same point |
| With no way to check whether a related contract was missed, you start from an exhaustive cross-check | The system narrows down the suspect spots first, and the person focuses their judgment on top of that |
Even so, the reason this scenario is worth validating on real contract data is the shape of the question. "Which contracts could conflict with this one?" is a question you can only answer by following lines from merchant to contract, and from contract to fee term. Store the contracts as entities and relationships, and you can follow those lines exactly as they are.