Consórcio Soberano is a technology platform for transactions between third-party cota holders and prospective buyers. It brings listing preparation, review, offers and documentary tracking into a controlled journey. It is not presented as an administradora de consórcios, and own-account purchase/resale is not the approved working model.

This guide separates an existing product journey from a proposed institutional connection. It is an explanatory document, not a commercial offer, institution mandate, regulatory certification or promise of automated transfer. Any partnership requires agreed scope, authority, responsibilities and acceptance criteria.

A separate panel supports operational work. Partner branding can be used with Soberano fallback. The intended self-service scope is display name, logo, brand color and support contacts; domains, legal identity, team permissions, fees and suspension remain controlled setup tasks. A complete connection to the partner's existing systems is not assumed.

1. The seller uploads a statement or enters cota information and supplies required documents.
2. The seller reviews extracted/entered data, sets the asking price and confirms applicable terms.
3. Operational checks assess source, identity/authority and applicable cota/transfer conditions.
4. An approved listing can become visible; eligibility to negotiate retains its own checks.
5. A buyer compares facts and submits an offer through the platform.
6. Acceptance, fees, contracts, payment and the administradora's registration each retain separate evidence and controls.

Document upload or extraction is not approval. Signature, payment acknowledgement or public proof is not ownership transfer. Cancelled/excluded cotas require their applicable rights and institution rules; they must not be marketed as automatically usable credit. Unsupported cases must be identified explicitly.

The asking price is what the seller requests, not the credit amount. Amount already paid, outstanding balance, installments and credit references are separate facts. Missing information is shown as unknown rather than zero. Historical statement values are not necessarily current balances.

Platform fees must come from the authoritative quotation and accepted version. Administrator transfer charges, remaining installments and other contractual costs are separate. No platform buyer fee, where applicable, does not mean the purchase has no other costs. A fee preview, accepted fee, paid amount and invoice are distinct records.

Intermediation, subscriptions, white-label licensing and implementation/services are commercial streams to be agreed for the relevant scope. This guide sets no binding price, partner commission, payout schedule or tax rate. Draft external tariffs do not activate collection or change accepted negotiations. Fiscal treatment and invoicing require validated accounting decisions.

The Passaporte da cota presents documentary references, financial context, lifecycle and available proof information. Each observation should retain its origin and freshness. Owner documentary payment history is not independently reconciled bank settlement or a guaranteed refund calculation.

New standard listings use explicit optional ConsorcioBlock election; older records may follow historical rules. Optional public proof can demonstrate a hash commitment when supported by actual network/finality facts. It does not independently validate every document statement, guarantee a cota, replace institution consent or authorize transfer. An approved optional-proof listing may remain visible while proof is processing, with pending status clearly shown.

The public buyer-verification passport has a stricter availability gate: the current implementation exposes it only after finalized Klever proof. A visible standard listing does not automatically have a public verified passport. Private owner documentary information and public verification are different views.

Personal/KYC documents are not intended for public-chain publication. Selected hashes and opaque references must remain separate from controlled private source material. Pending, failed, historical, final and unavailable proof states must not be collapsed into a verified badge.

The accepted design starts with one administradora and a reviewed manual process. It is not active for real institutional operations merely because its software exists. Production activation, institution onboarding and real-data scope require separate authorization and evidence.

The original B2C record stays in its original tenant. The initial pilot supports personal-owner sources; corporate-owner delegation is outside this initial scope. The institution receives no unrestricted customer inventory. An owner grants particular fields and optional documents for a stated purpose and limited time. A named reviewer also needs current company authority and an effective mandate.

Each fact is independent. Manual findings are clearly labelled manual, never API-verified. An observation does not bypass publication, institution consent, separation of maker/checker responsibilities or registration evidence. Sharing a whole PDF is broader than sharing selected fields and requires a separate explicit choice.

A portal with documented manual evidence is the first workable option. A read-only server-to-server connector is the next option when an actual partner contract exists. Batch import, event feeds and write automation are possible design topics, not capabilities promised by this guide. MCP is not a substitute for authorization or an institution's supported API.

Before connector work, the partner should supply:

• Named commercial and technical owners and authority for the pilot.
• Official versioned sandbox/API documentation, permitted operations and authentication requirements.
• Synthetic accounts/cotas and expected results, including exact group/cota/subcota identity rules.
• Field definitions, money/currency formats, status meanings, timestamps and freshness limits.
• Supported categories and restrictions, rate limits, errors, timeout/retry guidance and escalation contact.
• Agreed purpose, allowed fields, document-sharing responsibilities and acceptance process.

Secret values must use an approved secure setup channel, never a mobile bundle or ordinary chat. Certification starts with synthetic contract tests, then authorized sandbox reads, evidence review and explicit acceptance. Missing values, ambiguous identity, stale evidence, revocation, wrong tenant and provider failures must be tested. No provider adapter is certified by this guide. Write automation is a later, separately reviewed stage.

Identity, tenant/resource scope, company authority, MFA where required, revocable grants and disclosure auditing work together. Visibility of a button or a known record ID does not grant access. Data already disclosed cannot be remotely recalled merely by revoking future access. No universal prevention of copying or screenshots is promised.

Each party must agree who may access what, for which purpose, for how long, and how incidents/rights requests are handled. Retention and external-provider cleanup require an approved policy; anonymization is not a claim that every document or legally required record has been erased. No fixed legal retention period or certification is asserted here.

Soberano manages its platform controls; the partner confirms the authority, supported rules and evidence that it supplies. The administradora retains its applicable decision and registration responsibilities. Service hours, support response targets, availability and recovery commitments must be agreed, not inferred from the existence of a dashboard.

The web marketplace and separate panel exist. The Android application has an internal test distribution with native buyer/seller journeys and guides; this is not a Google Play production listing. Email/password and Google login have recorded user acceptance. Facebook activation, production push delivery and store publication remain pending. An Android APK does not run on iOS; an iOS release is not certified.

Current API monitoring is bounded to the running process. Persistent history, cross-replica aggregation and alert delivery are planned, not an uptime guarantee. Public-facing educational content explains the workflow but is not a substitute for an agreed contract or actual cota verification.

Start with a discovery session and an approved synthetic manual rehearsal. Resolve unsupported flows before live onboarding. Review this guide against the actual partner contract and current release before external reliance.

• Marketplace
• Buyer guide
• Seller guide
• Fees
• Control panel

These are entry points, not newly audited promises of every provider's availability. Partner-specific sandbox details are supplied only through the approved onboarding process.