Skip to the operations

Credit Bureaus

BigDataCorp in a decision flow.

6 BigDataCorp operations a decision flow can call directly, with the credentials your own contract issued. The response is data the rest of the flow reads, branches on, and keeps in the trace.

Category
Credit Bureaus
Type
Integration
Authentication
API key headers
Test environment
Production host only

Who they are

Brazilian data company selling registry, credit and fraud data through one API.

BigDataCorp aggregates public registries, court records, company filings, digital footprints and partner credit data into datasets a caller selects per query. Its customers are Brazilian lenders, insurers and marketplaces that need to know who they are dealing with before they commit. It publishes its per-dataset prices openly, which is rare in a market where most data contracts are negotiated.

What a flow can call

6 operations, each one a step you can place on the canvas.

  1. POST/pessoas

    Look up a person (registration data)

    Receita Federal registration data for a CPF — name, date of birth, tax status.

  2. POST/pessoas

    Pull the Quod credit score (person)

    The Quod credit score for a CPF, 300 to 1000, where lower is riskier.

  3. POST/pessoas

    Read digital financial behaviour (person)

    Six behavioural indicators graded A to H — credit seeking, payment-service use, online banking, investments, donations and card use.

  4. POST/empresas

    Look up a company (registration data)

    Registration data for a CNPJ. The company equivalent of the person lookup and the same first-node logic applies.

  5. POST/empresas

    Pull the Quod credit score (company)

    The Quod company credit score with its supporting indicators — payments on time, current arrears, borrowing, credit seeking and relationship stability.

  6. POST/empresas

    Look up an electronic invoice (NF-e)

    Reads a model 55 NF-e by its 44-digit access key — issuer, recipient and line items as recorded at issue.

Where it sits in the decision

Credit Bureaus calls have a natural place in a flow.

A bureau pull is the expensive call in a credit decision, so it belongs after the cheap eligibility rules that might make it unnecessary and before the scorecard that consumes it. What came back is kept with the decision: months later an adverse-action notice has to cite the file as it read at the time, not as the bureau would answer today.

Whatever BigDataCorp returns is part of the run, so it is part of the record. When someone asks months later why an applicant was declined, the answer cites what came back at the time rather than re-fetching from a service whose answer has since changed.

  • 01Add BigDataCorp as a connection authenticating with API key headers.
  • 02BigDataCorp has one host for both environments, so guard test runs with your own credentials and limits.
  • 03Place a Connection node and pick an operation — “Look up a person (registration data)” is usually the first one a flow needs.
  • 04Map the response into the fields your rules read, then test the whole path before it carries live traffic.

Common questions

Using BigDataCorp in a flow.

How do I connect BigDataCorp to a decision flow?

Add BigDataCorp as a connection in your workspace authenticating with API key headers, with the credentials your own contract issued — ArboRule calls the provider as you, and never holds a contract on your behalf. Once the connection exists, any flow in the workspace can place a Connection node and choose one of its operations. The credentials live on the connection, not in the flow, so a policy owner can use BigDataCorp in a decision without ever seeing the secret.

Can I test BigDataCorp without touching production?

BigDataCorp exposes one host for both environments, so there is no separate sandbox to point at. Test runs still execute in Sandbox and are recorded separately in decision history, but the call goes to the same place as production — so guard it with your own test credentials, rate limits, or data.

What can a flow call on BigDataCorp?

6 operations, including “Look up a person (registration data)”, “Pull the Quod credit score (person)”, “Read digital financial behaviour (person)”. Each one is a step you place on the canvas and map into the fields your rules read, and most flows start with “Look up a person (registration data)”. The list comes from the same manifest the engine uses to make the call, so this page cannot describe an operation the product does not have.

Where in a decision should BigDataCorp be called?

A bureau pull is the expensive call in a credit decision, so it belongs after the cheap eligibility rules that might make it unnecessary and before the scorecard that consumes it. What came back is kept with the decision: months later an adverse-action notice has to cite the file as it read at the time, not as the bureau would answer today.

Also in Credit Bureaus

Ready when you are

Wire BigDataCorp into a real decision.

Build the flow in Sandbox, connect your account, and watch the decision pull what it needs before it answers.

Read the docs