Open APIs

Hi, We are working on a capability for a telecom operator where Primary subscriber (John) can add othes subscribers (Smith, Adam) to his household and assign a relationship label to each - spouse, parent, child, sibling.

The managed connections (Smith, Adam) may be prepaid, postpaid, broadband, or DTH subscribers. They do not necessarily share a billing account with John. The relationship is purely a personal/household identity label - it does not affect billing, provisioning, or commercial terms.

The Question:
Should this relationship be stored at:

Option A - Customer level (TMF629)
On the primary subscriber's Customer.relatedParty[] with role = "managedAccount" and a characteristic[relationshipType = "friend"]:

------------------------------
Ajay
------------------------------

Constraint you stated 

1. Smith & Adam may not share a billing account with John
2. Relationship must not affect billing
3. Prepaid / Postpaid / Broadband / DTH mix

Putting a "spouse / parent / child" label on an Account would overload a commercial object with identity semantics - a classic anti-pattern that leaks into billing extracts, revenue reports, and dunning logic.

Why TMF629 (Customer) is correct ??

TMF629 represents the party engaged in a business relationship with the operator - i.e., the person/identity view, independent of what they buy or how they pay.

Household, family, and personal relationships are attributes of IDENTITY. They persist even if John churns a service, switches from postpaid to prepaid, or closes a billing account.

In TMF629 we can model this via the relatedParty construct (or, more purely, delegate to TMF632 Party Management which owns PartyRelationship)

// On John's Customer resource
{
  "id": "cust-john-001",
  "name": "John",
  "relatedParty": [
    {
      "id": "cust-smith-044",
      "name": "Smith",
      "role": "spouse",          // household label
      "@referredType": "Customer"
    },
    {
      "id": "cust-adam-088",
      "name": "Adam",
      "role": "child",
      "@referredType": "Customer"
    }
  ]
}

------------------------------
Nitin Srivastava
Jio Platforms Limited
------------------------------

Nitin's right that this belongs on the identity side, and the anti-pattern warning is the important part - a household label on an account leaks into dunning and revenue extracts, and you find out at the worst possible time.

I'd add three delivery caveats.

First, relatedParty[] on Customer is a reference list, not a resource. You can't add or revoke one relationship - you rewrite the array. Two care sessions touching the same household at once and one silently wins; there's no per-relationship id to PATCH, no audit of who added whom, and no clean way to answer "when did Adam become a child on this household". At small volumes you never see it. At scale it arrives as lost-update tickets nobody can reproduce. That's the real argument for TMF632 PartyRelationship as a first-class resource rather than as the "purer" option - it's the one that survives operations.

Second, and I'd check this before choosing an anchor at all: the model assumes every household member has a Customer. Where a prepaid line is a Party against an MSISDN and a Customer record only appears at postpaid conversion, John can add Smith today and Smith's identity can move or merge at conversion - now the relationship points at a party id that no longer resolves. In a prepaid/postpaid/broadband/DTH mix that's the normal case, not the edge case.

Third, a household label is a claim about someone else. Spouse or child isn't a fact John owns - it needs Smith's acceptance and Smith's ability to revoke, which means states (invited/accepted/revoked/expired), a timestamp and a source. An array of labels can't carry a state machine; a relationship resource can.

And "no billing impact" is true on day one. Every household capability I've been near eventually gets a shared allowance or a family discount pointed at it. If the relationship is a resource, that's a new offer. If it's a characteristic inside an array, it's a migration.

So before A or B: which system is the system of record for the relationship, and who is allowed to revoke it - the primary, the member, or care?

------------------------------
Rounak Talwar
Tecnotree
------------------------------

Original Message:
Sent: Jul 16, 2026 02:05
From: Nitin Srivastava
Subject: TMF629 vs TMF666 - Should household/family relationships between subscribers be stored on Customer.relatedParty[] or BillingAccount.accountRelationship[]?

Constraint you stated 

1. Smith & Adam may not share a billing account with John
2. Relationship must not affect billing
3. Prepaid / Postpaid / Broadband / DTH mix

Putting a "spouse / parent / child" label on an Account would overload a commercial object with identity semantics - a classic anti-pattern that leaks into billing extracts, revenue reports, and dunning logic.

Why TMF629 (Customer) is correct ??

TMF629 represents the party engaged in a business relationship with the operator - i.e., the person/identity view, independent of what they buy or how they pay.

Household, family, and personal relationships are attributes of IDENTITY. They persist even if John churns a service, switches from postpaid to prepaid, or closes a billing account.

In TMF629 we can model this via the relatedParty construct (or, more purely, delegate to TMF632 Party Management which owns PartyRelationship)

// On John's Customer resource
{
  "id": "cust-john-001",
  "name": "John",
  "relatedParty": [
    {
      "id": "cust-smith-044",
      "name": "Smith",
      "role": "spouse",          // household label
      "@referredType": "Customer"
    },
    {
      "id": "cust-adam-088",
      "name": "Adam",
      "role": "child",
      "@referredType": "Customer"
    }
  ]
}

------------------------------
Nitin Srivastava
Jio Platforms Limited
------------------------------

------------------------------
Nitin Srivastava
Jio Platforms Limited
------------------------------

Nitin, this is the right landing point - Party-anchored, first-class PartyRelationship, consent lineage per relationship. The bounded-service-inside-CRM framing is also the pragmatic version most operators can actually ship: separate domain and contracts now, separate application later as an infra call, not a data-model one.

One delivery caveat on the revoke model, because it's the part that bites in production.

Committing every revoke only after OTP to the member's registered channel is right for consent capture, but it quietly creates a relationship you can't withdraw the moment that channel goes stale - a ported-out number, a DTH-only member with no mobile on file, a primary who's simply unreachable. In a prepaid/postpaid/broadband/DTH mix those aren't edge cases, they're a standing tail. And it collides with the DPDP point you raised: the same regime that makes per-relationship consent lineage mandatory also guarantees the right to withdraw consent. An OTP-only gate can structurally deny that withdrawal at exactly the wrong moment - estrangement, fraud, an erasure request - because the second factor can never be delivered.

So the state machine probably needs a break-glass transition beside the happy path: a care-initiated revoke that commits under dual control, with a mandatory reason-code and a hard audit entry, used only when OTP delivery is provably impossible. Consent-by-default is right; consent-that-can-never-be-withdrawn is a different and worse failure. The per-relationship event stream you already want makes this clean - break-glass is just another transition with a stronger authorization guard, not a bypass.

Which raises the governance question I'd want settled before build: who owns that break-glass policy, and is an un-revokable relationship allowed to persist indefinitely, or does it force a review/expiry after N days so a dangling consent can't sit forever? That answer usually tells you whether the relationship resource is really owned by CRM or by compliance.

------------------------------
Rounak Talwar
Tecnotree
------------------------------

------------------------------
Nitin Srivastava
Jio Platforms Limited
------------------------------

Original Message:
Sent: Jul 19, 2026 01:14
From: Rounak Talwar
Subject: TMF629 vs TMF666 - Should household/family relationships between subscribers be stored on Customer.relatedParty[] or BillingAccount.accountRelationship[]?

Nitin, this is the right landing point - Party-anchored, first-class PartyRelationship, consent lineage per relationship. The bounded-service-inside-CRM framing is also the pragmatic version most operators can actually ship: separate domain and contracts now, separate application later as an infra call, not a data-model one.

One delivery caveat on the revoke model, because it's the part that bites in production.

Committing every revoke only after OTP to the member's registered channel is right for consent capture, but it quietly creates a relationship you can't withdraw the moment that channel goes stale - a ported-out number, a DTH-only member with no mobile on file, a primary who's simply unreachable. In a prepaid/postpaid/broadband/DTH mix those aren't edge cases, they're a standing tail. And it collides with the DPDP point you raised: the same regime that makes per-relationship consent lineage mandatory also guarantees the right to withdraw consent. An OTP-only gate can structurally deny that withdrawal at exactly the wrong moment - estrangement, fraud, an erasure request - because the second factor can never be delivered.

So the state machine probably needs a break-glass transition beside the happy path: a care-initiated revoke that commits under dual control, with a mandatory reason-code and a hard audit entry, used only when OTP delivery is provably impossible. Consent-by-default is right; consent-that-can-never-be-withdrawn is a different and worse failure. The per-relationship event stream you already want makes this clean - break-glass is just another transition with a stronger authorization guard, not a bypass.

Which raises the governance question I'd want settled before build: who owns that break-glass policy, and is an un-revokable relationship allowed to persist indefinitely, or does it force a review/expiry after N days so a dangling consent can't sit forever? That answer usually tells you whether the relationship resource is really owned by CRM or by compliance.

------------------------------
Rounak Talwar
Tecnotree
------------------------------