Saltar al contenido
AtalayaAtalaya
Volver

Metodología

Cómo construimos cada score, sin caja negra.

Esta página explica las fuentes, transformaciones y pesos que producen el Atalaya Score. Si una decisión de inversión depende de un número, ese número debe ser auditable. Aquí está el modelo entero.

Modelo · heuristic-v2026.04.23 · vision-v1

Fuentes

Cuatro fuentes oficiales, ingresadas directamente.

No revendemos listings. Cada activo se ingresa de la fuente original, se normaliza a un esquema único y se expone con trazabilidad por activo. Nunca un dato sin origen.

  • Solvia

    REST API · POST

    Inventario ex-Banco Sabadell gestionado por Cerberus. Hourly scrape, ~8.000 activos.

  • Aliseda

    REST API · GET

    Banco Santander + Blackstone. Aporta referencia catastral, coordenadas y estado de posesión cuando disponible.

  • Altamira

    REST API · POST

    doValue (multi-banco). Subastas extrajudiciales y pisos con campos enriquecidos publishedAt / lastPriceUpdate.

  • BOE

    HTML scrape + LLM

    Subastas judiciales del Boletín Oficial del Estado. Texto legal parseado con LLM → fase procesal, acreedor, depósito, ocupante vulnerable.

Score 0–100

Cinco componentes, pesos fijos, total 100.

Cada activo recibe un score entero entre 0 y 100. La suma de los pesos componentes es exactamente 100; no hay multiplicadores ni boosts ocultos. Un activo que no maximiza una componente pierde literalmente esos puntos.

ComponentePesoQué mide
Δ vs zona
30
Diferencia entre €/m² del activo y la mediana €/m² de su zona (cascade postal→municipal). Penaliza activos sobre-precio aunque tengan descuento publicado alto.
Estado físico
25
Análisis visual de fotos por modelo Haiku. Estados: óptimo, habitable, reformable, ruina. Pending_vision si no hay foto procesada (placeholder 14/25).
Posesión
20
Libre / ocupado / cedido / dudoso. Señales fuente + parsing BOE + datos catastrales cruzados.
Liquidez zona
15
Actividad de mercado en la zona del activo: nuevos listings/30d, rotación, demanda. Zonas alta/media/baja.
Cargas legales
10
Hipotecas vivas, embargos, anotaciones marginales. Tres capas (A/B/C) con peso decreciente.
Total100Suma fija. Sin boosts ni multiplicadores.

Niveles del score

90100

Exceptional

7589

Excellent

6074

Good

4059

Average

2039

Below avg

019

Poor

Cascade zonal

Resolución por niveles, fallback explícito.

El precio de zona usado para Δ-zona se resuelve cascadingamente. Cada nivel se intenta solo si el anterior no tiene muestra suficiente (mín. 20 transacciones por defecto). El nivel resuelto se registra en zoneRefUsed para auditoría posterior.

  1. 01

    01 · Código postal

    Mediana €/m² del CP exacto. Más preciso pero exige muestra suficiente. Fuente: dataset interno Atalaya.

  2. 02

    02 · Barrio

    Cuando CP no tiene muestra. Para grandes ciudades el barrio captura mejor variación que el municipio.

  3. 03

    03 · Municipio

    Mediana €/m² municipal de transacciones reales (no anuncios).

  4. 04

    04 · Provincia

    Último nivel del dataset interno cuando municipio no tiene muestra.

  5. 05

    05 · MITMA

    Fuente externa oficial: índices municipales del Ministerio de Transportes. Independiente del precio bancario, rompe el sesgo banco-vs-banco. Fallback final.

BOE legal parsing

Texto judicial bruto a campos estructurados.

Cada subasta BOE incluye texto legal denso. Atalaya extrae con un LLM propietario los campos clave que un inversor revisaría manualmente: NIF deudor, situación posesoria, cargas registrales, importe de salida, fecha de cierre. Schema versionado, fallback graceful si el modelo falla.

  • Fase procesal

    Ejecución hipotecaria · concurso · ejecución dineraria · administrativa. Define el riesgo procesal y los plazos.

  • Tipo de acreedor

    Banco · servicer · administración · particular. Indica perfil del proceso y predisposición negociación.

  • Depósito legal

    Importe del depósito requerido para participar en la subasta y plazos asociados.

  • Ocupante vulnerable

    Bandera de ocupación protegida (familia con menores, persona dependiente). Riesgo regulatorio relevante.

Visión computer-vision

Estado físico inferido de las fotos del listing.

Para los activos con fotos procesadas, un subagente Haiku evalúa: estado de cocina, baños, pintura, suelos, exterior. Salida estructurada con quality score, observations y bandera de alerts. Si no hay foto disponible o el procesamiento aún no se ha ejecutado, el activo queda como pending_vision con score físico placeholder de 14/25 — visible y trazable, nunca silenciado.

Versionado

Trazabilidad por activo, sin re-escribir el pasado.

Cada score lleva el promptVersion del modelo que lo generó. Cuando el modelo cambia, los scores anteriores no se re-escriben silenciosamente: se conserva el histórico y el nuevo cálculo se etiqueta con la nueva versión. El histórico es auditable desde el detalle de cada activo.

Empieza con datos auditables, no con promesas.