Guides
Part of Registered agent record: what the address proves and what it does not
Registered agent lookup data: a schema that cannot mislead
Registered agent lookup data as columns: store dated observations, key on the entity number, keep personal names out, and label the address.
A single record makes the agent field easy to read: it is where legal papers go. In a dataset of millions of records it needs a schema, because the column looks like a link between companies and it is not one. How you store it decides how it gets misread later.
Four decisions cover it: what to store, what to key on, what to leave out and what to print beside the value on screen. Each costs a line of design now and prevents a wrong conclusion later.
What to take away
- Store the agent as a dated observationthe value, the jurisdiction, the office's record date and the day you retrieved it.
- Key every row on the entity number with its jurisdiction, never on the address.
- Keep the raw address in its own column, named for what it is.
- Leave personal names out by default, and label the value as a service address wherever it appears.
- Compute flags on entities you already know instead of building links between entities you do not.
One row per observation
Store each agent record as a dated observation, not as an attribute of the entity. The agent on file is a statement about a record at a time, so the row needs the time.
| Column | Holds | Rule |
|---|---|---|
| Entity number and jurisdiction | The key | Always stored as a pair |
| Agent address, as filed | The address exactly as the office shows it | Own column, never merged with principal or mailing addresses |
| Agent address, cleaned | Your normalised copy | Derived, kept beside the raw value |
| Agent name | The name on the filing, where it names a business | Left out where it names a person |
| Record date | The date on the office's record | Never replaced by your retrieval date |
| Retrieved at | The moment you read it | Set on every pull |
Historical values are often unavailable from the office, so your own observations are the only series you will ever have.
What the column holds, and what to clean
The column holds a name and an address, as recorded on whichever filing last set them. Around that sit several complications you inherit whether you want them or not.
Formatting varies by state and often by filing within a state. Suite numbers may appear or not, abbreviations may be expanded or not, and the provider's corporate name may vary.
Commercial providers are flagged as such in some jurisdictions only, and historical values are often unavailable, so you get the current entry, not a series. The address may belong to an entirely different state's operation of the same provider.
Before any check, the field needs normalisation you cannot fully validate, and that is where quiet errors begin. Keep the raw value so the cleaning can be redone.
Key on the entity number, not the address
Match entities on the entity number with its jurisdiction, never on a normalised address. The number is the field designed to be unique, and the address is a delivery arrangement shared with whoever else uses the same provider.
A key built on the number also survives the changes that break other keys, a point set out in modelling filing history. Everything else in the row hangs off it as an observation.
Why the schema refuses an address join
A link is informative when the shared attribute is rare. A commercial agent exists to be one published point where legal papers can be served on an entity, so thousands of unrelated entities share the address.
The information in the link is close to zero. Joining on it does not aggregate weak evidence into strong evidence. It manufactures structure from the provider's customer list, and the artifact is stable and reproducible, which makes it look like a finding.
Shared agent address: inference vs reality
The inference
- Affiliation
- They share a supplier
- Hub of activity
- An office where mail is received
- Entity size
- Says nothing about operations
- State capital base
- Providers cluster near filing office
- Agent change
- Companies switch suppliers on price
- Same beneficial owner
- Field carries no ownership
Why it fails
- Affiliation
- Hub of activity
- Entity size
- State capital base
- Agent change
- Same beneficial owner
Every row is a version of one mistake: reading a delivery arrangement as a fact about the business. The single-record version of the same argument is in registered agent lookup.
If your schema makes it easy to link entities on agent address, someone will, and the resulting analysis will be confident and wrong. Make the harder path the default.
Personal names: default to not storing them
The column also contains the names of people, because plenty of small companies name an owner, an accountant or an attorney as agent. Counting how many entities someone is agent for measures their administrative work, not them.
Which uses of a dataset about individuals are regulated is a question for the relevant rules rather than for a design meeting. The Federal Trade Commission's guidance for businesses is the sensible first stop before anyone writes the join.
The defensible default is not to store personal name fields at all. Almost every legitimate question about a counterparty is answerable from entity-level fields, the scope described in secretary of state search facts.
What to print beside the value
If the value reaches a screen, the words next to it should say it is a service address for legal papers. This costs one line and prevents a whole class of error.
Never load the address into a generic address field. Otherwise somebody downstream will geocode the lot and map company locations that are partly agent offices.
Flags worth computing on known entities
The real uses of the field share a shape: you already know which entities you care about, and you are checking a specific condition on them.
- Vacancy or resignation.California requires by statute corporations, LLCs, limited partnerships and LLPs to designate an agent for service of process, so a missing agent is a gap against a requirement. It also moves an entity toward trouble, as registration status data sets out.
- Coverage before filing in a new state.Confirm your provider covers the jurisdiction before the registration goes in.
- Agent address is the only address held.A data quality alert, not an accusation: you have not established a place of business.
- Unchanged agent record.Entities whose agent has not changed since an office move are possibly stale entries.
Run these on your own entities or on a defined list of counterparties you have a reason to watch, never as a sweep of the register.
Common questions
Are shared addresses ever informative?
Sometimes the address is not an agent's and few entities share it, which is a different situation from two entities at a provider's address. First establish which kind you have, then confirm it against the wider record, not the address alone.
Can I use agent data to find every company in a group?
No. Group structure is not in this field, and reconstructing it from a register generally is not possible. The reliable route is the counterparty itself, plus whatever they file.
What about a very small agent serving a handful of entities?
Then the base rate is different, and the observation is weakly informative rather than empty. It is still not evidence of a relationship, and if the agent is an individual, the caution above applies with more force rather than less.
