Module 6: FinTech and data products

This session treats ALT/FNDATA itself as the teaching case: how does a raw, messy, physical-world dataset such as auction and resale transaction records become a commercial data product with a schema, an access tier structure, and a REST API. Students examine the three access surfaces a real data vendor maintains (a no-code sandbox, documentation with a client library, and a production API) and discuss the product and business decisions behind each one, including why self-serve access and manually issued API keys serve different customer segments. The session closes with students sketching their own access-tier design for a hypothetical alternative data product, using ALT/FNDATA's structure as a reference point rather than a template to copy exactly.

Target course(s) and level

FinTech product design, data product management, or technology entrepreneurship course. Suitable for MBA students and graduate students in a technology management or product concentration; pairs well with Module 4 in a course that covers both the investment use case and the product-design perspective on the same dataset.

Learning objectives

By the end of this session, students will be able to:

  1. Describe the three access surfaces of a data product (no-code sandbox, documentation and client library, production API) and the distinct customer need each one serves.
  2. Explain the tradeoffs between self-serve access and manually issued credentials, using API key provisioning as a concrete example.
  3. Read and interpret a REST API's request and response shape, including endpoint, headers, filters, and pagination.
  4. Identify what a data dictionary and coverage browser contribute to a data product's usability, separate from the raw data itself.
  5. Design a basic access-tier structure for a hypothetical data product, justifying which tier gets self-serve access and which requires manual approval.
  6. (Extension) Issue a working API request using the reusable Python client and interpret the response envelope.

Prerequisites

An introductory course in product management, technology strategy, or entrepreneurship. No coding background is strictly required for the core session; the optional code extension assumes basic Python familiarity and comfort running a script.

Materials and access needed

  • Sandbox access at sandbox.altfndata.com, self-registered with a work or school email, auto-approved, used as the primary teaching artifact for the no-code tier.
  • Documentation site at docs.altfndata.com, including the quickstart, task-based tutorials, the Evaluation Guide at use-cases.html, and the downloadable client (altfndata_client.py).
  • For the optional extension: an instructor class API key requested from info@altfndata.com, distributed to student groups for the API demo segment only.
  • Projector or screen share for the instructor demo, and a whiteboard or shared document for the access-tier design exercise.

Session outline (90 minutes)

  • 0 to 15 min: Introduce the three access surfaces (sandbox, documentation, production API) and why a data vendor maintains all three rather than just one.
  • 15 to 30 min: Guided demo, sandbox as the no-code, self-serve tier.
  • 30 to 45 min: Guided demo, documentation and client library as the on-ramp to programmatic access.
  • 45 to 60 min: Guided demo, production API request and response shape, including the optional live code extension.
  • 60 to 75 min: Small-group exercise, students design an access-tier structure for a hypothetical alternative data product.
  • 75 to 88 min: Group share-out of access-tier designs.
  • 88 to 90 min: Wrap-up and homework assignment.

In-class demo (sandbox-first, no code)

  1. Open sandbox.altfndata.com and register with a work or school email. Point out to students that approval is automatic, which is a deliberate product decision to remove friction for the self-serve tier.
  2. Walk through the SQL editor, coverage browser, data dictionary, and schema tabs. Ask students which of these components exist purely to make the raw data usable, as opposed to storing new information.
  3. Run a simple query against the fine art data table to show the sandbox functioning end to end, using the query in the "Datasets and queries used" section below.
  4. Switch tabs to docs.altfndata.com and show the quickstart page, the task-based tutorials, and the Evaluation Guide at use-cases.html. Ask students who they think each of these pages is written for.
  5. Show the downloadable Python client (altfndata_client.py) and the runnable tutorials notebook without running any code yet, describing what each file contains.
  6. Explain the manual API key issuance process: keys are requested from the ALT/FNDATA team, not self-served, and discuss as a class why a vendor might gate the production API tier behind manual approval while leaving the sandbox open.
  7. (Optional extension, code) Using the instructor's class API key, project a single live request through the Python client that mirrors the sandbox query from step 3, and show the response envelope containing table, result_count, and data.
  8. Point out that result_count reflects only the current page of results, not the total match count, and discuss why pagination design choices like this matter for a product's API consumers.

Datasets and queries used

Dataset: fine art data (documented fields: designer, model, item_title, sale_date, usd_price_decimal, sale_estimates_high_usd_price, status, vendor, stock_ticker).

Sandbox SQL editor query used in step 3:

SELECT item_title, sale_date, usd_price_decimal, vendor
FROM all_fine_art_data
WHERE status = 'sold'
ORDER BY sale_date DESC
LIMIT 25;

Optional API extension, equivalent request body (POST /v1/tables/all_fine_art_data/query, header X-API-Key):

{
  "fields": ["item_title", "sale_date", "usd_price_decimal", "vendor"],
  "filters": [
    {"field": "status", "op": "eq", "value": "sold"}
  ],
  "sort": [{"field": "sale_date", "direction": "desc"}],
  "limit": 25
}

Corresponding response envelope shape, shown to students as-is:

{
  "table": "all_fine_art_data",
  "result_count": 25,
  "data": [
    {"item_title": "...", "sale_date": "...", "usd_price_decimal": 0, "vendor": "..."}
  ]
}

Discovery endpoints referenced in the demo: GET /v1/tables (lists available tables) and GET /v1/tables/{name}/schema (returns the field list and types for a given table).

Discussion questions

  1. Why might a data vendor make the sandbox self-serve and auto-approved while keeping the production API behind manual key issuance?
  2. What does the response envelope's separation of result_count (this page) from the actual total tell you about the design tradeoffs behind pagination?
  3. What is the purpose of a data dictionary and a coverage browser in a data product, separate from the underlying data tables themselves?
  4. If you were designing pricing tiers for this product, what would distinguish a tier meant for an individual analyst from a tier meant for an institutional desk running automated queries?
  5. What risks does a vendor take on by offering a no-code sandbox with real production data, rather than a sample or synthetic dataset?
  6. How would you decide which of your product's features belong in documentation and tutorials versus which belong in the tool itself?
  7. What would you want to measure to know whether your access-tier design is working, once real customers start using it?

Homework assignment

Each student or student pair designs a one-page access-tier proposal for a hypothetical alternative data product of their choosing (it does not need to relate to luxury goods or ALT/FNDATA). The proposal must define at least three access tiers, specify for each tier whether access is self-serve or manually approved and why, sketch the shape of one example API request and response for the top tier, and identify one risk of the proposed design, drawing an explicit comparison to at least one specific design choice observed in ALT/FNDATA's sandbox, documentation, or API during the session (for example, the choice to auto-approve the sandbox but manually issue production API keys). Deliverable: a one-page written proposal plus a simple diagram of the three tiers, submitted as a single PDF. Grading criteria: clarity and specificity of the tier design (30 percent), quality of the self-serve versus manual-approval justification (25 percent), correctness and realism of the sketched API request and response (25 percent), and thoughtfulness of the identified risk (20 percent).