# Client Portfolio Management: From Legal Data to Delivery Tracking ## In commodity brokerage, a client is not a contact. It is a living file. There is a dangerous little lie in many trading teams. It sounds like this: “We have the client in CRM.” Very good. What exactly do you have? A company name? A phone number? A Telegram handle? A person called “Dmytro buyer maybe”? A PDF from 2021? A bank account copied from an email? A legal address from an old contract? A note that says “good client” written by someone who left six months ago? This is not a client portfolio. This is a drawer full of clues. In commodity brokerage, a client is not just a contact. A client is a live operating file: legal identity, beneficial ownership, authorized signatories, bank details, active bids and offers, trade history, documents, delivery batches, payment status, execution notes, broker ownership, risk flags and audit history. If this sounds like too much for one “client card,” that is exactly the point. A normal CRM thinks a client is someone you call. A commodity brokerage workspace should understand that a client is someone you may contract with, ship to, invoice, pay, audit, blacklist, forgive once, never forgive again, or call at 7:42 p.m. because a vessel window just became everyone’s problem. ## The problem: client data is scattered by default Most brokerage teams do not start with a clean operating system. They start with reality. Reality usually looks like this: - company details in one spreadsheet; - bank details in an email; - legal documents in a folder; - contact people in Telegram; - old trades in someone’s memory; - current bids in a monitor, sheet or chat; - contract comments in a PDF; - delivery status in an operations thread; - payment notes in accounting; - and the “latest version” of everything in a place known only to the person currently on holiday. This works until it does not. And it usually stops working at the worst possible moment. The deal is ready. The buyer is serious. The seller is ready. The broker has moved the sides close enough. Everyone can almost smell the commission. Then someone asks: “Is this the correct legal name?” A small silence. Then: “Which bank account are we using?” A longer silence. Then: “Who is authorized to sign?” Now the silence has management qualities. The cost of fragmented client data is not just time. It is execution risk. A wrong bank account, an outdated signatory, a missing registration extract, an old legal address or an unverified counterparty can block a deal right at the point where everyone thought the hard part was over. This is why client cards in commodity brokerage must be operational documents, not decorative contact records. ## Legal data is the foundation layer A serious client profile starts with legal identity. Not because lawyers enjoy long PDFs, although some clearly do. Because the legal profile determines whether the company can actually stand behind a contract, receive an invoice, issue payment, pass internal approval, and survive basic counterparty review without everyone suddenly discovering “one more document.” For a corporate commodity client, the legal layer may include: - full legal name; - registration number; - jurisdiction; - legal address; - company registration extract; - tax details; - authorized representatives; - signatory powers; - beneficial ownership; - ownership structure; - bank details; - correspondent bank details where relevant; - regulatory status if applicable; - sanctions / PEP / watchlist screening status; - internal risk label; - KYC refresh date; - document expiry or review schedule. This is not bureaucracy for decoration. KYC procedures are designed to identify and verify customers, understand ownership and funds, and reduce financial crime risk. In the asset-management context, B4Finance describes KYC as including customer identification, source-of-funds checks, risk profiling, ongoing monitoring and traceable archiving. For corporate clients, documentation can become fairly serious. Mipise lists examples such as business-register extracts, bank account details, company bylaws, representative IDs, beneficial-owner registry extracts, tax records or financial statements, regulatory authorizations, organization charts, shareholder lists and proof of legal representatives. Commodity brokerage is not the same as asset management, and this article is not legal advice. But the operating lesson is universal: if a client’s legal data is incomplete, old or scattered, the trade lifecycle starts with a crack in the foundation. And cracks have a habit of becoming visible when the roof is already on fire. ## KYC is not a checkbox. It is a live field. The old way to think about KYC is: “We collected the documents.” The better way is: “What is this client’s current compliance state?” That difference matters. A client may be fully onboarded today and need a refresh later. Ownership may change. Bank details may change. A new signatory may appear. A jurisdiction may become sensitive. A client may move from “normal” to “needs review” because of payment behavior, delivery failures, sanctions screening, or internal experience. B4Finance describes risk profiling, regular updates, verification cycles and audit-proof archiving as part of modern KYC/AML obligations, and lists risk segmentation as a best practice. In a commodity brokerage workspace, this means KYC status should not be buried in a folder. It should be a live field on the client card. For example: - KYC status: complete / incomplete / expired / needs refresh; - risk label: low / medium / high / prohibited; - review type: simplified / standard / enhanced; - last reviewed date; - next review date; - missing documents; - responsible person; - notes for brokers and execution. This is not only about compliance. It is about not wasting commercial time on counterparties that cannot pass the next step. The market already has enough ways to waste time. We do not need to invent new ones with stale PDFs. ## The deal layer: client context must connect to market flow A client card that is not connected to live market activity is not portfolio management. It is a polite archive. The operational value begins when the client profile is connected to: - active offers; - active bids; - matches; - counters; - trades; - open execution records; - documents; - invoices; - payment status; - delivery history; - broker ownership; - internal notes. This is where commodity brokerage differs from generic CRM. In many industries, a CRM can be mostly relationship history: calls, emails, opportunities, pipeline stage, forecast, maybe a nice chart that makes management feel temporarily calm. In commodity brokerage, the client is part of the market flow. A buyer is not just “interested.” They are interested in a commodity, volume, basis, price, delivery window, quality, destination, and payment structure. A seller is not just “available.” They may have a specific cargo, quality, origin, shipment period, storage point, or logistical constraint. So the client card must answer practical questions: - What does this client usually buy or sell? - Which commodities are active? - What basis do they usually work on? - Which broker owns the relationship? - Who is the main contact? - What are the legal and bank details? - Which deals are open? - Which trades moved into EXE? - What delivery issues happened before? - What payment behavior does the team remember? - What should we not forget next time? If the answer is “ask someone in the chat,” the client portfolio is not managed. It is being passed around like a hot potato with documents attached. ## Broker ownership is governance, not office politics Broker ownership may sound like an internal HR detail. It is not. In brokerage, “assigned broker” and “main broker” define accountability. They answer a simple but very important question: Who owns the relationship and who is responsible for moving this client through the operating line? This matters because client ownership affects: - who can update the profile; - who sees the full relationship context; - who gets follow-up reminders; - who owns the next action; - who can request details from another broker; - who is accountable if the client becomes inactive; - who should be involved when a trade moves into execution. Without clear ownership, the client becomes “everyone’s client.” And “everyone’s client” often becomes nobody’s responsibility. A structured brokerage workspace should make client ownership visible without turning the team into a medieval land dispute. The goal is not to create politics. The goal is to prevent chaos. ## EXE: where legal data becomes contractual reality Post-trade is where the polite fiction ends. Before trade, missing client data is annoying. After trade, it can be fatal. Once a trade moves toward execution, client data becomes contractual reality. Legal names, signatories, bank details, addresses, tax data, delivery instructions and document requirements stop being “reference fields” and start appearing in contracts, addenda, invoices, payment instructions, commission packages, and delivery documents. This is why the trade lifecycle depends on upstream data quality. Intuition’s overview of the trade lifecycle describes pre-trade, execution, clearing, settlement and ongoing risk management, and emphasizes that trading requires planning and follow-up beyond the transaction moment itself. It also describes trade capture, enrichment and validation, with validation serving as a final check before communication with other entities begins. Limina similarly frames post-trade processing as the work after execution that aims to ensure a smooth path to settlement and validate that systems and service providers have represented the trade correctly. It highlights confirmation, affirmation, settlement and reconciliation as core post-trade activities. In physical commodity brokerage, the same idea becomes very tangible. A trade is not complete because someone wrote “done” in a chat. A trade becomes real when the legal entity, contract terms, delivery obligations, documents, invoices, payments and execution steps all line up. If the client card is weak, EXE becomes detective work. And execution teams have enough work without becoming archaeologists. ## The client card should feed the contract, not haunt it A commodity contract should not require people to manually reconstruct client identity from old emails. The client profile should feed downstream documents. At minimum, the workspace should keep clean: - legal entity name; - trading name, if different; - registration number; - legal address; - VAT/tax details; - authorized signatories; - bank accounts; - correspondent bank details; - standard contractual notes; - default invoice recipient; - default delivery / documentation contacts; - risk notes; - internal restrictions. This does not mean every contract becomes fully automated on day one. But it does mean the source of truth is clear. If bank details change, there should be a visible history. If a legal name is corrected, it should not silently mutate old records without an audit trail. If a signatory changes, the system should not rely on someone remembering that “the old director is no longer valid, I think.” Because “I think” is not an execution control. It is a weather forecast. ## Delivery tracking is part of client portfolio management In physical commodity trading, the deal is not truly done at contract signing. That is just the moment everyone starts discovering how good the earlier data really was. The real operating endpoint is delivery: cargo dispatched, vessel loaded, batch confirmed, weight certificates issued, quality documents accepted, invoices sent, payment done, commission closed. Delivery tracking is therefore not a logistics side quest. It is part of the client portfolio. A client’s delivery history tells you things that a CRM note never will: - Do they perform on time? - Do they accept documents smoothly? - Do they dispute quality often? - Do they pay as expected? - Do they cause repeated logistics delays? - Do they require special handling? - Do their trades often need addenda? - Are they commercially attractive but operationally painful? - Are they reliable enough for larger exposure? CapSpire’s discussion of commodity logistics systems frames movement management as a bridge between trade execution and logistics, centralizing scheduling, tracking and reconciliation to improve transparency and control across the supply chain. It also notes that commodity-specific logistics differ by transport, storage, units of measure and quality specifications, and that auditable tracking of physical movements is important for governance and reporting. LSEG’s commodities shipping product page similarly points to supply-chain visibility across water, ports and vessel positions, including real-time feeds of vessel positions and developments, and interactive mapping for supply-chain dynamics. For a broker, the lesson is simple: A client’s delivery history is not “operations data.” It is commercial intelligence. ## Delivery history is a reliability signal Client reliability is not just a feeling. It can be observed. A client may be pleasant, responsive, and completely charming right until the second invoice. Another client may write like a tractor manual but execute perfectly. The portfolio should remember both. Useful client reliability signals include: - on-time delivery rate; - frequency of addenda; - quality disputes; - payment delays; - document correction frequency; - cancelled trades; - failed deliveries; - average time from trade to contract; - average time from contract to delivery confirmation; - invoice aging; - open action count; - repeated logistics exceptions; - broker notes after execution. A normal CRM may say “good relationship.” A useful commodity workspace should say: “Good relationship, but last three trades needed delivery extensions and one invoice sat unpaid for 21 days.” That is not cynicism. That is memory. And memory is one of the few things that can stop a team from making the same expensive mistake twice. ## Governance: the audit layer that makes it defensible Client data changes. Legal names change. Bank accounts change. Brokers get reassigned. Delivery places get cleaned. Commodity names get normalized. Templates change. Commission packages are corrected. Documents are replaced. Someone archives a value that should not appear in new trades. Without an audit layer, all of this becomes folklore. With an audit layer, it becomes governance. The system should know: - who changed the field; - when they changed it; - what the old value was; - what the new value was; - why the change was made; - whether it was applied immediately; - whether it required review; - whether it affected active records; - whether a document or event was attached. B4Finance lists audit-proof archiving and traceability as part of modern KYC/AML obligations and notes that records should be stored for at least five years in the asset-management context. Duco’s post-trade lifecycle article makes a broader operational point: post-trade breaks often come from data problems not caught early enough, manual errors, or systems that cannot keep pace. It also highlights that clean, timestamped, enriched trade data is required for accurate reporting and downstream workflows. In physical commodity brokerage, the same rule applies in plain language: If you cannot explain what changed, when, by whom, and why, you do not have governance. You have a memory game with invoices. ## The operating line: Clients → Deals → EXE A proper commodity brokerage workspace should connect three layers: **Clients** Legal identity, ownership, contacts, bank details, risk label, broker assignment, notes, documents, and relationship history. **Deals** Offers, bids, matches, counters, trades, prices, basis, commodities, delivery places, quantities, publication text, and market movement. **EXE** Contracts, confirmations, addenda, invoices, delivery status, payment state, commission packages, and execution tasks. The point is not to make everything complicated. The point is to stop pretending that these are separate worlds. They are not. A client profile feeds a deal. A deal becomes a trade. A trade moves into EXE. EXE produces delivery and payment history. That history flows back into the client profile. The next broker sees a better picture. That is portfolio management. Not a list of contacts. A loop. ## What MN7R is trying to solve here MN7R is built around this operating idea: keep live market positions, client context and post-trade execution in one working line instead of splitting them across chats, separate files and disconnected tools. That means client management is not a side menu. It is part of the trade lifecycle. A client card should show not only who the client is, but what they are doing, who owns the relationship, what they need, what they bought or sold, what moved to execution, what still needs documents, what delivery issues happened, and what the team should remember next time. In MN7R terms, this means connecting: - client cards; - assigned and main broker ownership; - legal and contact details; - offers and bids; - matches and trades; - EXE records; - reference data; - business events; - delivery and payment follow-up; - governance history. The aim is not to turn brokers into data-entry clerks. That would be cruel and probably illegal in spirit. The aim is to make the work brokers already do leave a clean operating trace. So the next step is easier. The next trade is safer. The next report is faster. The next mistake is less likely to be the same as the last one. ## A practical client portfolio model A commodity brokerage client card should not be huge because someone enjoys tabs. It should be complete because the work demands it. A practical model could look like this: **1. Identity** Legal name, short name, registration number, jurisdiction, addresses, tax data. **2. People** Decision-makers, signatories, operational contacts, finance contacts, logistics contacts. **3. Bank and payment** Bank accounts, SWIFT/IBAN, correspondent banks, payment terms, invoice contacts, payment notes. **4. Compliance and risk** KYC status, risk tier, sanctions screening, UBO status, document completeness, review date. **5. Broker ownership** Main broker, assigned broker, team, relationship notes, handover history. **6. Market activity** Active offers, active bids, matches, counters, trades, inactive opportunities. **7. Execution** Contracts, confirmations, addenda, delivery records, invoices, payments, commission status. **8. Delivery history** Batches, shipment status, quality certificates, weight confirmations, delays, exceptions. **9. Audit and events** Who changed what, when, why, and whether the change was approved, pending, applied, rejected or replaced. Now the client is no longer a contact. It is an operating object. And that is the only way to manage a serious portfolio in physical commodity brokerage. ## The final point Commodity brokerage is not just relationship management. It is relationship management under the pressure of physical goods, documents, legal entities, delivery windows, payment terms, logistics constraints and execution risk. A client is not a phone number. A client is not a Telegram chat. A client is not a row in CRM. A client is a live file that starts with legal identity and ends, if the team does its job properly, with delivered goods, clean documents, paid invoices and a relationship worth using again. That is why the future of client portfolio management in commodity brokerage is not “better CRM.” It is an integrated operating layer. From legal data to delivery tracking. From market flow to execution. From memory to audit. And from “I think we have it somewhere” to “open the client card.” Which is not poetry. But in brokerage, it is close enough. --- ## Explore MN7R MN7R is a commodity brokerage workspace for broker teams: Clients, Deals, EXE, reference data governance, role-based visibility and structured communication. It is built for teams that need live market flow, client context and post-trade execution in one operating line. [Explore MN7R](https://mn7r.com/) [Read the MN7R Blog](https://mn7r.com/blog) --- ## Sources and context This article uses public references on KYC/AML, trade lifecycle management, post-trade operations, commodity logistics and shipping visibility to frame the operational logic of client portfolio management in physical commodity brokerage. - B4Finance: KYC/AML obligations, risk profiling, ongoing monitoring, audit-proof archiving and the commercial role of compliance. https://www.b4finance.com/blog/understanding-kyc-aml-compliance-in-asset-management - Mipise: examples of corporate KYC documentation requirements for investment and asset-management contexts. https://www.mipise.com/en/platform_blog_posts/the-importance-of-kyc-procedures-for-asset-management-and-investment-funds-companies- - Intuition: five-stage trade lifecycle and the importance of trade capture, enrichment and validation. https://www.intuition.com/the-lifecycle-of-a-trade-5-key-stages/ - Limina: post-trade management, confirmation, affirmation, settlement and reconciliation. https://www.limina.com/blog/guide-post-trade-management-software - capSpire: commodity logistics movement management, scheduling, tracking, reconciliation and auditable physical-movement control. https://capspire.com/mastering-commodity-logistics-in-openlink-commodities/ - LSEG: commodities shipping visibility, vessel positions and supply-chain dynamics. https://www.lseg.com/en/data-analytics/products/workspace/commodities/shipping - Duco: post-trade lifecycle breaks caused by data issues, manual processes and insufficient system capability. https://du.co/post-trade-lifecycle-management/